TCC是Try、Confirm、Cancel三个词语的缩写，TCC分为3个阶段
- Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
- Confirm 阶段：如果所有分支的Try都成功了，则走到Confirm阶段。Confirm真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源
- Cancel 阶段：如果所有分支的Try有一个失败了，则走到Cancel阶段。Cancel释放 Try 阶段预留的业务资源
流程
成功
失败
假如Confirm/Cancel操作遇见失败会怎么样？按照Tcc模式的协议，Confirm/Cancel操作是要求最终成功的，遇见失败的情况，都是由于临时故障或者程序bug。
总结
优点：
- TCC 只适合短事务
- 允许开发人员根据业务需求灵活定义每个阶段的操作逻辑。可使TCC模式适用于各种复杂的分布式事务场景。
- TCC模式通过将事务拆分为Try、Confirm和Cancel三个阶段，避免了传统的锁机制带来的并发性能问题
- 由于无锁设计和阶段化的执行，TCC模式具有良好的并发性能。各个参与者可以并行执行Try和Confirm阶段的操作，减少了事务冲突和等待时间。
- TCC模式对于 RM 的故障和系统崩溃有一定的容错性。在Confirm阶段，事务的确认操作将确保事务的最终提交；而在Cancel阶段，事务的撤销操作将恢复资源到事务之前的状态，保证了系统的可靠性和故障恢复能力。
缺点：
- 相对于传统的ACID事务模型，TCC模式的实现相对复杂。需要开发人员仔细设计和实现每个阶段的操作逻辑
- 由于TCC模式的阶段执行方式，可能存在部分阶段执行成功而后续阶段失败的情况。这可能导致数据的不一致性，需要通过应用程序层面的补偿机制或人工干预来解决。
- 不同 RM 之间需要进行额外的网络通信来协调事务的执行。这可能增加系统的网络开销和延迟。