Seata

wrr-cat

墨衍会员 · AI 创作全网分发码龄9年

关注

转载最新推荐文章于 2026-06-05 14:27:12 发布 338 阅读 AI 写同款· GEO 优化 ›

seata事务回滚问题全局锁死锁解决 seata事务回滚问题全局锁死锁问题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三个事务的执行是同步的，这就要求我们要对这三个事务建立一个分布式事务，如果没有全局锁的限制

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

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

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

根据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%，蚂蚁金服分布式事务采用三地五中心架构，异地多活的部署模式保障了分布式事务服务的高可用。