本篇文章介绍 Seata 中的四种不同的事务模式的特点及优缺点及其使用场景。

• XA 模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC 模式：最终一致的分阶段事务模式，有业务侵入
• AT 模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA 模式：长事务模式，有业务侵入

无论哪种方案，都离不开 TC(事务协调者)，也就是事务的协调者。

1. XA模式

XA 规范 是 X/Open 组织定义的分布式事务>分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的 TM(事务管理者) 与局部的 RM(资源管理者) 之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

1.1 两阶段提交

XA 是一种规范，目前主流数据库都实现了这种规范，实现的原理都是 基于两阶段提交。

正常情况:

异常情况：

一阶段：

• 事务协调者通知每个事物参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

• 事务协调者基于一阶段的报告来判断下一步操作
  • 如果一阶段都成功，则通知所有事务参与者，提交事务
  • 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

1.2 Seata 的 XA 模型

Seata 对原始的 XA 模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM 一阶段的工作：

​ ① 注册分支事务到TC

​ ② 执行分支业务sql但不提交

​ ③ 报告执行状态到TC

TC 二阶段的工作：

• TC检测各分支事务执行状态

  a.如果都成功，通知所有RM提交事务

  b.如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

1.3 XA 优缺点

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则。
• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务
  
  

1.4 实现XA模式

Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：

1）修改application.yml文件（每个参与事务的微服务），开启 XA 模式：

seata:data-source-proxy-mode: XA

2）给发起全局事务的入口方法添加 @GlobalTransactional 注解:

本例中是OrderServiceImpl中的create方法.

3）重启服务并测试

重启 order-service，再次测试，发现无论怎样，三个微服务都能成功回滚。

2. AT 模式

AT 模式同样是 分阶段提交的事务模型，不过缺弥补了 XA 模型中资源锁定周期过长的缺陷。

2.1 Seata 的 AT 模型

基本流程图：

阶段一 RM 的工作：

• 注册全局事务及分支事务
• 记录 undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态

阶段二提交时RM的工作：

• 删除 undo-log 即可(异步)

阶段二回滚时RM的工作：

• 根据 undo-log 恢复数据到更新前

2.2 AT 流程梳理

用一个真实的业务来梳理下AT模式的原理。

比如，现在又一个数据库表，记录用户余额：

id	money
1	100

其中一个分支业务要执行的SQL为：

update tb_account set money = money - 10 where id = 1

AT模式下，当前分支事务执行流程如下：

一阶段：

1）TM发起并注册全局事务到TC

2）TM调用分支事务

3）分支事务准备执行业务SQL

4）RM拦截业务SQL，根据where条件查询原始数据，形成快照。

{"id": 1, "money": 100
}

5）RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90

6）RM报告本地事务状态给TC

二阶段：

1）TM通知TC事务结束

2）TC检查分支事务状态

​ a）如果都成功，则立即删除快照.

​ b）如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为100

流程图：

2.3 AT 与 XA 的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
• XA模式强一致；AT模式最终一致

2.4 AT 的脏写问题

在多线程并发访问AT模式的分布式事务>分布式事务时，有可能出现脏写问题，如图：

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

2.5 AT 的优缺点

AT模式的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

• 两阶段之间属于软状态，属于最终一致
• 框架的快照功能会影响性能，但比XA模式要好很多

2.6 实现 AT 模式

AT 模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。

1）导入数据库表，记录全局锁

2）修改application.yml文件，将事务模式修改为AT模式即可：

seata:data-source-proxy-mode: AT # 默认就是AT

3）重启服务并测试

3. TCC模式

TCC 模式与 AT 模式非常相似，每阶段都是独立事务，不同的是 TCC 通过人工编码来实现数据恢复。需要实现三个方法：

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

• Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。

• Cancel：预留资源释放，可以理解为try的反向操作。

3.1 流程分析

举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

• 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

初识余额：

余额充足，可以冻结：

此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

• 阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30

确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：

此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

• 阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

需要回滚，那么就要释放冻结金额，恢复可用金额：

3.2 Seata的TCC模型

Seata 中的 TCC 模型依然延续之前的事务架构，如图：

3.3 优缺点

TCC模式的每个阶段是做什么的？

• Try：资源检查和预留
• Confirm：业务执行和提交
• Cancel：预留资源的释放

TCC的优点是什么？

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
• 软状态，事务是最终一致
• 需要考虑Confirm和Cancel的失败情况，做好幂等处理

4. SAGA模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。

其理论基础是 Hector & Kenneth 在1987年发表的论文 Sagas。

Seata官网对于Saga的指南：https://seata.io/zh-cn/docs/user/saga.html

4.1 原理

在 Saga 模式下，分布式事务>分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

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

Saga也分为两个阶段：

• 一阶段：直接提交本地事务
• 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

4.2 优缺点

优点：

• 事务参与者可以基于事件驱动实现异步调用，吞吐高
• 一阶段直接提交事务，无锁，性能好
• 不用编写TCC中的三个阶段，实现简单

缺点：

• 软状态持续时间不确定，时效性差
• 没有锁，没有事务隔离，会有脏写

5. 四种模式对比

从以下几个方面来对比四种实现：

• 一致性：能否保证事务的一致性？强一致还是最终一致？
• 隔离性：事务之间的隔离性如何？
• 代码侵入：是否需要对业务代码改造？
• 性能：有无性能损耗？
• 场景：常见的业务场景

	XA	AT	TCC	SAGA
一致性	强一致性	弱一致性	弱一致性	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有, 要编写三个接口	有, 要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性,隔离性有高要求的业务	基于关系型数据库的大多数分布式事务>分布式事务场景都可以	对性能要求较高的事务. 有非关系型数据库要参与的事务	业务流程长, 业务流程多. 参与者包含其他公司或遗留系统服务, 无法提供 TCC 模式要求的三个接口的业务