SpringCloud - 分布式事务二（Seata-AT，TCC，Saga）

建议在阅读这篇文章的时候先理解 XA 的模式，否则很难有一个概念去阅读本文。有关 XA 模式查看 (opens new window)

以下是 Seata 框架，先理解这个后续理解不同模式对其有所帮助

# AT 模式

AT 模式是一种无侵入的分布式事务解决方案。阿里 seata 框架，实现了该模式。seata AT 模式官方地址 (opens new window)

在 AT 模式下，用户只需关注自己的 “业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

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

# 一阶段：

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

# 二阶段提交：

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

# 二阶段回滚：

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

# 总结

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

# TCC 模式

TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。

TCC 三个方法描述：

• Try：资源的检测和预留；
• Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
• Cancel：预留资源释放；

# TCC 的实践经验

蚂蚁金服 TCC 实践，总结以下注意事项:
➢ 业务模型分 2 阶段设计
➢ 并发控制
➢ 允许空回滚
➢ 防悬挂控制
➢ 幂等控制

# 1 TCC 设计 - 业务模型分 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 TCC 设计 - 允许空回滚

Cancel 接口设计时需要允许空回滚。在 Try 接口因为丢包时没有收到，事务管理器会触发回滚，这时会触发 Cancel 接口，这时 Cancel 执行时发现没有对应的事务 xid 或主键时，需要返回回滚成功。让事务服务管理器认为已回滚，否则会不断重试，而 Cancel 又没有对应的业务数据可以进行回滚。

# 3 TCC 设计 - 防悬挂控制

悬挂的意思是：Cancel 比 Try 接口先执行，出现的原因是 Try 由于网络拥堵而超时，事务管理器生成回滚，触发 Cancel 接口，而最终又收到了 Try 接口调用，但是 Cancel 比 Try 先到。按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的 Try 接口不应该执行，否则会产生数据不一致，所以我们在 Cancel 空回滚返回成功之前先记录该条事务 xid 或业务主键，标识这条记录已经回滚过，Try 接口先检查这条事务 xid 或业务主键如果已经标记为回滚成功过，则不执行 Try 的业务操作。

# 4 TCC 设计 - 幂等控制

幂等性的意思是：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。因为网络抖动或拥堵可能会超时，事务管理器会对资源进行重试操作，所以很可能一个业务操作会被重复调用，为了不因为重复调用而多次占用资源，需要对服务设计时进行幂等控制，通常我们可以用事务 xid 或业务主键判重来控制。

# saga 模式

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

如图：T1-T3 都是正向的业务流程，都对应着一个冲正逆向操作 C1~C3

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

Saga 正向服务与补偿服务也需要业务开发者实现。因此是业务入侵的。

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

# Saga 模式使用场景

Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。

事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，可以使用 Saga 模式。

# Saga 模式的优势与缺点

# 优势

• 一阶段提交本地数据库事务，无锁，高性能；
• 参与者可以采用事务驱动异步执行，高吞吐
• 补偿服务即正向服务的 “反向”，易于理解，易于实现；

# 缺点

Saga 模式由于一阶段已经提交本地数据库事务，且没有进行 “预留” 动作，所以不能保证隔离性。后续会讲到对于缺乏隔离性的应对措施。

# 注意

与 TCC 实践经验相同的是，Saga 模式中，每个事务参与者的冲正、逆向操作，需要支持：

• 空补偿：逆向操作早于正向操作时；
• 防悬挂控制：空补偿后要拒绝正向操作
• 幂等

# 总结 AT、TCC、Saga、XA 模式分析

四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景：

• AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎 0 学习成本。
• TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
• Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。
• XA 模式是分布式强一致性的解决方案，但性能低而使用较少。

资料来源 (opens new window)

该图为 Seata XA 模式