Seata

seata

如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

在 Seata 中，分布式事务的执行流程：

• TM 开启分布式事务（TM 向 TC 注册全局事务记录）；

• 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；

• TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；

• TC 汇总事务信息，决定分布式事务是提交还是回滚；

• TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。

2.3 分布式事务 Seata 解决方案

Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。

2.3.1 AT 模式

今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

AT 模式如何做到对业务的无侵入 ：

• 一阶段：

• 以下文中的行锁都是全局锁

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，之后要获得本地锁，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁，然后再释放本地锁。最后一阶段执行完毕，事务只持有一个行锁。这样保证了一阶段操作的原子性。

• 二阶段提交：

二阶段TC根据所有的分支事务执行结果判断，如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁(全局锁)删掉，完成数据清理即可。

• 二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

为什么要有行锁（全局锁）呢？

试想一下，我们有三个事务，分别是A、B、C，业务要求A、B、C三个事务的执行是同步的，这就要求我们要对这三个事务建立一个分布式事务，如果没有全局锁的限制

1. A事务在本机执行完毕，释放本地锁

2. B事务在本机执行完毕，释放本地锁

3. C事务在本机执行完毕，释放本地锁

4. 根据A、B、C三个事务执行状态，二阶段决定提交还是回滚

• 看起来好像没什么问题，但是如果在A事务执行完毕，释放锁的时候，A2事务也要执行，并且修改A事务修改过的数据，如果没有全局锁，会导致A事务失效，为了分布式事务的一致性，需要添加全局锁作为保障。

• 并且二阶段会进行脏数据的校验，相当于又加了一层保护。

2.3.2 TCC 模式

2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。

TCC 三个方法描述：

• Try：资源的检测和预留；

• Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；

• Cancel：预留资源释放。

业务模型分 2 阶段设计：

用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。

以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段 Try 成功的话 二阶段 Confirm 一定能成功。

如上图所示，

Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的 转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。

二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。

如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。

用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。

2.3.3 Saga 模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

2.3.4 XA 模式

XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。

XA 协议有一系列的指令，分别对应一阶段和二阶段操作。“xa start”和 “xa end”用于开启和结束XA 事务；“xa prepare” 用于预提交 XA 事务，对应一阶段准备；“xa commit”和“xa rollback”用于提交、回滚 XA 事务，对应二阶段提交和回滚。

在 XA 模式下，每一个 XA 事务都是一个事务参与者。分布式事务开启之后，首先在一阶段执行“xa start”、“业务 SQL”、“xa end”和 “xa prepare” 完成 XA 事务的执行和预提交；二阶段如果提交的话就执行 “xa commit”，如果是回滚则执行“xa rollback”。这样便能保证所有 XA 事务都提交或者都回滚。

XA 模式下，用户只需关注自己的“业务 SQL”，Seata 框架会自动生成一阶段、二阶段操作；XA 模式的实现如下：

• 一阶段：

在 XA 模式的一阶段，Seata 会拦截“业务 SQL”，在“业务 SQL”之前开启 XA 事务（“xa start”），然后执行“业务 SQL”，结束 XA 事务“xa end”，最后预提交 XA 事务（“xa prepare”），这样便完成 “业务 SQL”的准备操作。

• 二阶段提交：

执行“xa commit”指令，提交 XA 事务，此时“业务 SQL”才算真正的提交至数据库。

• 二阶段回滚：

执行“xa rollback”指令，回滚 XA 事务，完成“业务 SQL”回滚，释放数据库锁资源。

XA 模式下，用户只需关注“业务 SQL”，Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案；但与 AT 模式不同的是，XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成，这样 XA 模式实现更加轻量化。

分布式事务在蚂蚁金服的实践

蚂蚁金服从 2007 年开始研发和应用分布式事务中间件，用 TCC 模式解决各类金融场景的数据一致性问题，后续又演进出 FMT（AT）、XA、Saga 等模式，各种模式分别适用于各类业务场景。我们决定将蚂蚁金服多年的技术积累开源出来，与社区共享蚂蚁金服的科技成果。

蚂蚁金服内部的分布式事务产品，在实现原理和使用方式上，与 Seata 类似，不同的是，为了支持双十一，对性能进行了极致优化，为了支持金融系统的高可用容灾，借助蚂蚁金服三地五中心架构实现了分布式事务服务的高可用容灾；接下来主要介绍蚂蚁金服在性能优化和高可用容灾方面的实践经验。

3.1 极致性能优化

3.1.1 同库模式

通常，一个 TM 会产生一笔主事务日志，一个 RM 会产生一条分支事务日志，每个分布式事务由一个 TM 和若干 RM 组成，一个分布式事务总共会有 1+N 条事务日志（N 为 RM 个数）。

在默认情况下，分布式事务执行过程中客户端将事务日志发送给服务端，服务端再将事务日志存储至数据库中，一条事务日志的存储链路会有 2 次 TCP ，分别是“客户端到服务端”和“服务端到数据库”， 我们称这种模式为异库模式。

在异库模式下，分布式事务存储事务日志总共需要 2*（1+N） 次左右的 TCP 通信。在 RM 数量较少的业务场景下，分布式事务性能还能接收，但有些业务场景下 RM 数量较多，此时事务内 TCP 数量也会增多，分布式事务性能急剧下降。

在事务执行过程中，客户端和服务端进行通信的目的是为了存储事务日志。如果客户端在存储事务日志时，绕过服务端直接将事务日志写入数据库（如上图“同库模式”所示），那么一笔事务日志的存储链路就由原来的 2 次 TCP 变成只需访问一次数据库便可，每条事务日志的存储减少了一次 TCP 通信，整个分布式事务就减少了 N+2 次 TCP 请求，分布式事务的性能大幅提升。我们将客户端直接将事务日志存储至数据库的模式称为同库模式。

3.1.2 二阶段异步执行

通常情况下，分布式事务发起方会依次执行一阶段和二阶段方法，然后结束分布式事务，返回结果。如果让分布式事务发起方执行完一阶段之后马上结束并返回结果，二阶段交由独立的线程或者进程异步执行，这样分布式事务的二阶段会晚几秒钟或者若干分钟执行，但事务的最终结果不会有任何改变。

二阶段异步执行之后，分布式事务的最终结果不会有任何影响，但是事务发起方要执行的内容减少一半（一阶段和二阶段都执行变成只执行一阶段），直观的用户感受是分布式事务的性能提升了 50%。

3.2 分布式事务高可用

为了保障金融系统的高可用，分布式事务服务必须达到 99.99% 的可用率。分布式事务使用了蚂蚁金服的三地五中心架构部署，在每个机房都独立部署分布式事务服务，分布式事务服务是无状态的，而底层数据库副本在各机房间也是双向同步，这样业务流量从一个机房切到另外一个机房，分布式事务服务不会对业务有任何影响，从而保证了分布式事务服务的高可用。

总结

在分布式架构演进中，蚂蚁金服对数据库进了水平拆分，对服务面向功能进行了服务化拆分，从而出现了跨服务、跨数据库的业务数据一致性挑战。

2007 年，蚂蚁金服自主研发分布式事务中间件经历 12 年的严苛业务锤炼。2019 年，将多年的技术积累分享给开源分布式事务 Seata，并持续投入社区共建。目前 Seata 提供了 AT、TCC、Saga 和 XA 四种模式，每一种模式分别有各自的应用场景，丰富的解决方案帮助用户解决给了各类场景的数据一致性问题。

最后一部分，分享了蚂蚁金服具体的实践。为了支持双十一的高性能需求，对分布式事务进行了极致的性能优化，例如同库模式、二阶段异步执行。为了使金融服务的可用性达到 99.99%，蚂蚁金服分布式事务采用三地五中心架构，异地多活的部署模式保障了分布式事务服务的高可用。