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

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

GTS 今年双 11 的成绩

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

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

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

GTS 带来的价值

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

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

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

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

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

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

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

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

GTS 的原理和创新

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

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

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

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

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

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

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

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

执行阶段：

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

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

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

完成阶段：

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

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

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

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

分布式事务模式融合及标准化（保护）

截止目前，还没有任何一种分布式事务的技术方案，可以满足所有场景的问题。GTS 的 AT 模式适用于绝大部分常见场景，但仍有一些场景更适合于使用业界其他的分布式事务解决方案。GTS 会把各类解决方案融合到 GTS 提供的云服务框架中，为云原生应用提供一站式的分布式事务服务。

这是 GTS 的抽象出的事务框架。通过这个抽象，分布式事务得以从整体架构中剥离出来，形成一个单独的技术切面，作为服务提供给应用。

简单来说，基于这个框架的应用，其分布式事务问题，就收敛到基于 RM 的分支事务机制和 TC 提供的稳定、可靠的服务中。分而治之，才能更有效地解决问题。

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

下面列出 4 种事务模式的优劣，以及在 GTS 的事务框架中的映射。

AT

优势： 业务无侵入；轻量，不依赖数据库的高级特性；回滚较少的场景性能高。

劣势： 隔离性不高，目前只能支持到接近 读已提交 的程度，更高的隔离级别，实现成本将非常高。

TCC

优势： 适用场景广泛；隔离性和性能都可以做极致优化。

劣势： 业务侵入性非常高。

Saga

优势： 长事务。

劣势： 有一定业务侵入性；隔离性差。

XA

优势： 业务无侵入；隔离性好。

劣势： 阻塞协议。

GTS 与开源

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

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

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

总结

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

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

 

 

 

 

原文链接

本文为阿里云内容，未经允许不得转载。

来源：oschina

链接：https://my.oschina.net/u/4209562/blog/3143562