介绍

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

• Try：资源的检测和预留
• Confirm：完成资源操作业务；要求Try成功Confirm一定要能成功
• Cancel：预留资源释放，可以理解为Try的反向操作

Seata中的TCC模型流程图
:::

空回滚和业务悬挂

空回滚

:::tips 当某分支事务的Try阶段阻塞时，可能导致全局事务超时而触发二阶段的Cancel操作，在未执行Try操作时先执行了Cancel操作，这时Cancel不能做回滚，就是空回滚
:::

业务悬挂

:::tips 对于已经空回滚的业务，之前被阻塞的Try操作恢复，继续执行Try，就永远不可能Confirm或Cancel ，事务一直处于中间状态，这就是业务悬挂

因此执行Try操作时，应当判断Cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的Try操作，避免业务悬挂 :::

优缺点

:::tips TCC模式的优点

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

TCC模式的缺点

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