SpringCloud：分布式事务Seata事务模式

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

1.AT 模式

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

1.1.前提

• 基于支持本地ACID事务的关系型数据库。
• Java应用，通过 JDBC访问数据库。

1.2.整体机制

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：
  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

在一阶段，Seata会拦截业务SQL，首先解析SQL语义，找到业务SQL要更新的业务数据，在业务数据被更新前，将其保存成before image，然后执行业务SQL更新业务数据，在业务数据更新之后，再将其保存成after image，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段如果是提交的话，因为业务SQL 在一阶段已经提交至数据库， 所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

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

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

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模式高很多。

3.Saga模式

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

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

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

3.1.适用场景

• 业务流程长、业务流程多
• 参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口

3.2.优势

• 一阶段提交本地事务，无锁，高性能
• 事件驱动架构，参与者可异步执行，高吞吐
• 补偿服务易于实现

3.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模式实现更加轻量化。