vlambda博客
学习文章列表

分布式事务 GTS 的价值和原理浅析

来自:阿里巴巴中间件

GTS 今年双 11 的成绩



今年 2684 亿的背后,有一个默默支撑,低调到几乎被遗忘的中间件云产品——GTS(全局事务服务,Global Transaction Service),稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。


2019 年 11 月 1 日至 12 日,GTS 日均处理分布式事务数量达 亿级 ,每天峰值 TPS 达 万级 。


这背后最重要意义在于:成绩是在给业务应用的设计和开发带来 0 负担 的前提下得到的。



GTS 带来的价值



随着企业的发展,企业业务架构面临数据、服务的分布化,几乎无可避免地要遇到分布式架构带来的数据一致性问题。


GTS 开创性地把分布式事务问题从业务中剥离出来,作为一个独立的技术切面来单独管理,以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。


GTS 给业务应用带来的价值体现在以下几个方面:


  • 架构复杂度降低:分布式事务这个 切面 的技术问题,全部 收敛 到 GTS 提供的服务来解决。
  • 设计和开发成本减轻:业务逻辑的设计和开发,完全不需要针对是否涉及分布式事务而做任何额外的事情,对业务 0 侵入 。
  • 项目交付、迭代速度加快:归因于上述两点,项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力,在这个商业机会瞬息万变的时代,显得尤为重要。


设想一个典型的云原生企业应用的成长路径:


分布式事务 GTS 的价值和原理浅析


  • 1.0:单体应用,快速上线,这个时候完全不涉及分布式事务。
  • 2.0:单个数据库无法支撑,数据分布到多个数据库,产生分布式事务问题。
  • 3.0:微服务化,进一步产生跨服务的分布式事务。
  • 4.0:跨应用的整合,成为 SaaS 或 FaaS 的平台,在更大的范围,产生分布式事务问题。


基于 GTS 提供的分布式事务服务,企业发展各阶段产生的不同场景下的数据一致性问题,可以得到一站式的解决。这使得业务可以平滑自然地,像搭积木一样成长起来。


从上面示例可以看到:GTS 实际上是把分布式事务(或者说分布式场景下的数据一致性)能力,作为一种 云原生 的服务,提供给生长在云上的应用,让分布式事务不再成为业务要面临的一个令人头疼的问题,而成为一种可以弹性伸缩,按需取用的服务能力。



GTS 的原理和创新



下面,从几个方面来大体介绍 GTS 的原理和创新。


首先,GTS 把分布式事务定义为由若干本地事务(分支)组成的全局事务。被全局事务管理的全部分支,将在协调器的协调下,保证一起成功或一起回滚。


分布式事务 GTS 的价值和原理浅析


其次,GTS 定义了一个事务模型,把整个全局事务过程模型化为 TM、RM、TC 三个组件之间协作的机制。


  • Transaction Coordinator (TC):事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
  • Transaction Manager (TM):控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
  • Resource Manager (RM):控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。


分布式事务 GTS 的价值和原理浅析


一个典型的分布式事务过程:


  1. TM 向 TC 申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的 XID。
  1. XID 在微服务调用链路的上下文中传播。
  1. RM 向 TC 注册分支事务,将其纳入 XID 对应全局事务的管辖。
  1. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
  1. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。


第三,GTS 创新地基于 SQL 解析实现对业务无侵入的自动补偿回滚机制。这种机制,GTS 将其命名为 Auto Transaction (AT) 模式。基本工作原理如下:


GTS 把全局事务分为两个阶段:执行阶段 和 完成阶段 。


执行阶段:


GTS 的 JDBC 数据源代理通过对业务 SQL 的解析,把业务数据在更新前后的数据镜像组织成回滚日志,利用 本地事务 的 ACID 特性,将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。


这样,可以保证:任何提交的业务数据的更新一定有相应的回滚日志存在。


分布式事务 GTS 的价值和原理浅析


基于这样的机制,分支的本地事务便可以在全局事务的 执行阶段 提交,马上释放本地事务锁定的资源。


完成阶段:


  • 如果 TM 发出的决议是全局提交,此时分支事务此时已经完成提交,不需要同步协调处理(只需要异步清理回滚日志),完成阶段 可以非常快速地完成。


分布式事务 GTS 的价值和原理浅析


  • 如果 TM 发出的决议是全局回滚,RM 收到协调器发来的回滚请求,通过 XID 和 Branch ID 找到相应的回滚日志记录,通过回滚记录生成反向的更新 SQL 并执行,以完成分支的回滚。


分布式事务 GTS 的价值和原理浅析


最后,GTS 通过事务协调器集群以及对业务应用节点的容错,实现一个拒绝单点故障的高可用服务。


分布式事务 GTS 的价值和原理浅析


一方面,GTS 服务集群机制,保障任意服务节点宕机,可以其他节点无缝接管。
另一方面,应用任意节点的宕机,相应事务分支的请求也会路由到连接相同数据库的其他节点上,不影响全局事务的完整执行。



GTS 的事务模式



截止目前,还没有任何一种分布式事务的技术方案,可以满足所有场景的问题。GTS 的 AT 模式适用于绝大部分常见场景,但仍有一些场景更适合于使用业界其他的分布式事务解决方案。


当前分布式应用层面,最具代表性的事务模式有 4 种,分别是 AT、TCC、Saga 和 XA,这些模式各有优缺点和适用的场景。


AT 模式


优势:业务无侵入;轻量,不依赖数据库的高级特性;回滚较少的场景性能高。
劣势:隔离性不高,目前只能支持到接近 读已提交 的程度,更高的隔离级别,实现成本将非常高。


TCC 模式


优势:适用场景广泛;隔离性和性能都可以做极致优化。
劣势:业务侵入性非常高。


Saga 模式


优势:适用于长事务场景。
劣势:有一定业务侵入性;隔离性差。


XA 模式


优势:业务无侵入;隔离性好。
劣势:较重的依赖;阻塞协议。


上述事务模式,AT 和 TCC 已经在 GTS 中提供了支持(TCC 模式在 GTS 中当前的名字是 MT),Saga 和 XA 也在研发过程中。

GTS 会把各类解决方案融合到 GTS 提供的云服务框架中,为云原生应用提供一站式的分布式事务服务。



GTS 与开源



为了更好地构建一个云原生的分布式事务标准,2019 年初,GTS 选择了开源,发起了开源项目 Seata(曾用名 Fescar)。项目开源不到 1 年时间,收获 STAR 数已经突破 1.2 万,Contributor 超过 120 名,获得社区的广泛关注和认可。


 Seata:https://github.com/seata/seata


分布式事务一直以来都可以称得上是世界性难题,希望可以通过 SEATA 这个开放的平台,聚集全世界的智慧来给这道难题交上一份让人满意的答卷。


进一步,GTS 将这份答卷转化为阿里云上高效、稳定、可靠的服务,赋能给广大云原生开发者。



总结



GTS 自从 2014 年诞生于阿里巴巴中间件的 5 年来,从支撑集团内第一个业务方开始,经历了从内部到云产品化,从封闭到开源,从单一模式到兼容并蓄和标准化,一直坚定地走在分布式事务领域的最前沿。


GTS 的目标是成为云原生时代,分布式事务的全面解决方案。任何分布式事务需求,在 GTS 上都能找到满意的答案。

作者信息:

煊檍,GitHub ID:sharajava,阿里巴巴中件间 GTS 研发团队负责人,SEATA 开源项目发起人,曾在 Oracle 北京研发中心多年,从事 WebLogic 核心研发工作。长期专注于中间件,尤其是分布式事务领域的技术实践。


长按订阅更多精彩▼

如有收获,点个在看,诚挚感谢