第7章 分布式系统架构 【补充：分布式事务解决方案之TCC】

本节内容来自“作者：小白不想上班 链接：https://www.jianshu.com/p/0f50adfc9992”，有部分补充内容

14.4. 分布式事务解决方案之TCC

14.4.1 什么是TCC事务

TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。

执行分布式事务的各方必须要实现以下三个接口：

（1）Try接口，负责执行分布式事务前的准备，包括对事务的各方是否能成功执行该事务进行校验，以及在执行事务前进行准备工作，如将状态置为“准备”状态等。

（2）Confirm接口，负责真正执行分布式事务，执行完不等待立即提交，以获得更好的系统并发。

（3）Cancel接口，负责一方执行事务失败后对其他各方进行事务补偿，将刚才的操作抵消回来。因此Cancel通常是Confirm操作的反向操作。

TCC是怎么执行分布式事务的？

（1）首先：业务应用会发起一个事务。这时，业务应用会到事务协调器中注册一个事务，然后调用事务的各方执行Try接口。接着，各方执行Try接口去进行事务前的验证。如果其中一方失败了，就没有必要执行该事务了，因此业务应用会通知事务协调器注销该事务，事务以失败结束。如果各方都验证成功，那么业务应用就会通知事务协调器启动事务。

（2）紧接着，执行分布式事务的任务就交给事务协调器。事务协调器首先调用事务各方的Confirm接口执行事务操作，采用“操作完不等待立即提交”的策略，杜绝了等待状态，从而获得了极大的系统并发。如果各方的执行都成功，则通知事务协调器，事务执行结束 。

但是，如果其中一方执行失败，自己本地首先执行回滚，然后通知事务协调器。接着，事务协调器就会通知其他各方执行Cancel接口，进行“事务补偿”，事务执行失败。

TCC方案不能保证完全的事务一致性，只能保证最终一致性。不能保证事务一致性的有两个环节：

（1）执行Confirm接口的速度不一致，先执行完的就提交了，但执行慢的还处理于更新前状态，但最终各方执行完了，事务就一致了。

（2）其中一方失败了，其他各方执行Cancel接口时，事务不一致，但Cancel接口执行完了，事务就一致了。

“最终一致性”的含义是，它有一段时间事务不一致，然而过了那段时间事务就一致了。

这里还有一个问题，就是有一方执行Confirm接口失败而另一方执行Cancel接口也失败，该如何处理？注意，不要试图解决一些小概率事件而做复杂设计，那样不划算。因此，最佳的解决思路就是写日志、找运维。

分支事务成功情况：

 

TCC 分为三个阶段：

Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。

Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用 TCC 则认为 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功。若 Confirm 阶段真的出错了，需引入重试机制或人工处理。

Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。

TM 事务管理器

TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当 TM 的角色，TM 独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。

TM 在发起全局事务时生成全局事务记录，全局事务 ID 贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于 Confirm 和 Cancel 失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同。

14.4.2 TCC 异常处理

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂：

（1）空回滚

在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行 Try 阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的 Cancel 方法，从而形成空回滚。

解决思路关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过 TM 在发起全局事务时生成全局事务记录，全局事务 ID 贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

（2）幂等

通过前面介绍已经了解到，为了保证 TCC 二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

解决思路在上述"分支事务记录"中增加执行状态，每次执行前都查询该状态。

（3）悬挂

悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

出现原因是在 RPC 调用分支事务 Try 时，先注册分支事务，再执行 RPC 调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM 就会通知 RM 回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，"分支事务记录"表中是否已经有二阶段事务记录，如果有则不执行 Try。

举例，场景为 A 转账 30 元给 B，A 和 B 账户在不同的服务。
方案

账户 A

try:
    检查余额是否够30元
    扣减30元
confirm:
    空
cancel:
    增加30元

帐户B

try:
    增加30元
confirm:
    空
cancel:
    减少30元

方案说明：

（1）账户 A，这里的余额就是所谓的业务资源，按照前面提到的原则，在第一阶段需要检查并预留业务资源，因此，我们在扣钱 TCC 资源的 Try 接口里先检查 A 账户余额是否足够，如果足够则扣除 30 元。Confirm 接口表示正式提交，由于业务资源已经在 Try 接口里扣除掉了，那么在第二阶段的 Confirm 接口里可以什么都不用做。Cancel 接口的执行表示整个事务回滚，账户A回滚则需要把 Try 接口里扣除掉的 30 元还给账户。

（2）账号B，在第一阶段 Try 接口里实现给账户 B 加钱，Cancel 接口的执行表示整个事务回滚，账户 B 回滚则需要把 Try 接口里加的 30 元再减去。
方案问题分析

如果账户 A 的 Try 没有执行在 Cancel 则就多加了 30 元。

由于 Try、Cancel、Confirm 都是由单独的线程去调用，且会出现重复调用，所以都需要实现幂等。

账号 B 在 Try 中增加 30 元，当 Try 执行完成后可能会其它线程给消费了。

如果账户 B 的 Try 没有执行在 Cancel 则就多减了 30 元。
问题解决

账户 A 的 Cancel 方法需要判断 Try 方法是否执行，正常执行 Try 后方可执行 Cancel。

Try、Cancel、Confirm方法实现幂等。

账号 B 在 Try 方法中不允许更新账户金额，在 Confirm 中更新账户金额。

账户 B 的 Cancel 方法需要判断 Try 方法是否执行，正常执行 Try 后方可执行 Cancel。
优化方案
账户 A

try:
    try幂等校验
    try悬挂处理
    检查余额是否够30元
    扣减30元
confirm:
    空
cancel:
    cancel幂等校验
    cancel空回滚处理
    增加可用余额30元

帐户B

ry:
    空
confirm:
    confirm幂等校验
    正式增加30元
cancel:
    空

14.4.3 小结

如果拿 TCC 事务的处理流程与 2PC 两阶段提交做比较，2PC 通常都是在跨库的 DB 层面，而 TCC 则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 Try、Confirm、Cancel 三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

TCC方案仅是一个解决方案，即一种设计思路。要落地TCC方案，可以选择阿里的GTS，它是SEATA的一个开源版。

采用TCC最大的缺点是工作量太大，每个正向操作都必须反向操作，开发工作量增大一倍，设计较复杂 。