在分布式事务解决方案中有 Seata AT模式，但是AT模式要求是关系型数据库（因为 undolog表需要和业务保持原子性），此时如果事务中存在非关系型数据库（如 Redis、 ES等），那么 AT模式就无法满足要求了，如下图所示：

此时我们就需要 Seata TCC模式来帮助我们解决这种场景下的分布式事务问题。

1、认识Seata TCC模式

TCC(Try-Confirm-Cancel)模式是一种补偿性事务模式的解决方案，因为补偿的业务需要使用者自己写，不像AT模式那样的无侵入性的分布式事务处理方案，如下是TCC模式的执行流程图：

TCC将一个完整的业务操作分为三个阶段，如下图整理所示：

Try阶段：尝试执行业务操作，预留必要的业务资源，并检查数据的有效性。

Confirm阶段：如果Try阶段所有参与的操作都成功，则进入Confirm阶段就会正式完成业务操作，提交事务，并释放在Try阶段预留的资源。

Cancel阶段：如果Try阶段有任何一个操作失败，或者由于某种原因需要回滚事务，则触发Cancel阶段，撤销所有已执行的Try操作，回滚到事务开始之前的状态，并释放预留的资源。

2、理解TCC模式

为了方便理解TCC模式，以A（账户总额1000元）向B（账户总额2000元）转账100元为例进行解析，那么TCC模式下的操作流程如下图所示：

Try阶段的工作：A账户先从总资金中扣除100元，但是这个100处于冻结状态；B账户预增加100元，这个100处于不可用状态。如下图所示：

（a）如果A与B在Try阶段都正常的执行，接下来就是执行Confirm阶段的任务，A账户冻结100变成0元，这个100真正的转给B账户；B账户的总额增加100元，预增加的金额变成0元，如下图所示：

（b）如果A与B在Try阶段未正常的执行，接下来A账户的冻结100变成0元，恢复A账户的资金的总额；B账户资金的总额不变化，预增加的金额变成0元，如下图所示：

3、Seata TCC事务模型的三种异常

在TCC事务模型涉及到的三种异常（空回滚、幂等性、防悬挂）是不可避免的，下面我们来了解这三种异常发生的原因以及处理方案。

（1）空回滚

A调用C的时候，由于网络抖动的原因导致C没有请求成功，此时服务超时走兜底机制返回异常给A，如下图所示：

当A发现B服务异常，TC就会通知A、B、C执行回滚操作，但是C由于Try阶段都没有执行就直接执行Cancel阶段，最终就可能导致业务数据的不一致性。

空回滚处理方案：

Cancel执行的前提是一定要执行过Try阶段，所以增加一个日志表来记录是否执行Try阶段，如果没有执行Try阶段，那么Cancel阶段也不执行。

（2）幂等性

TCC中二阶段的方法被多次的调用（二阶段会有定时器不断的重试），如下如所示：

幂等性处理方案：状态机方式

在日志表中执行更新操作的时候（update log set status= 2 where status= 1）通过获取影响行数来判断是否执行成功，如果影响行数为0就不继续处理；如果影响行数不为0就继续Cancel的业务逻辑。

（3）防悬挂

由于网络拥堵等原因导致A调用C的Try方法的请求发送成功，但是C与A之间自动断开了连接，导致A认为C执行异常了，此时TC发送执行回滚操作命令，这就导致Cancel阶段比Try先执行，如下图所示：

当C服务做完Try阶段的工作后，此时资源被预留出来了；但是Cancel已经执行完成了，表示那么整个事务就结束了，进而导致业务数据的不一致性。

防悬挂问题的处理方案：日志表

在Cancel执行完成之后要保证Try方法不能再执行了，此时在日志表中增加一条Cancel的记录，等到Try执行的时候，其也要增加一条记录，但是由于Cancel增加了日志记录，此时Try就增加失败，进而阻止Try继续执行。

总结：

（1）TCC模式资源锁定时间短：相较于传统的两阶段提交(2PC)，TCC模式可以减少资源锁定的时间，因为资源仅在Try阶段被预留，并在Confirm或Cancel阶段迅速释放。

（2）TCC模式业务逻辑灵活：我们可以根据业务需求自定义每个阶段的逻辑，使得TCC模式非常灵活。

（3）TCC模式保证强一致性：它可以确保事务要么都成功，要么都回滚。

（4）TCC模式实现复杂（需要为每个业务操作明确定义Try、Confirm和Cancel三个阶段的逻辑）、增加了协调开销、业务侵入性（业务逻辑与事务逻辑耦合）。