TCC
快速开始 · changmingxie/tcc-transaction Wiki (github.com)
tcc的一个demo看了 5种分布式事务方案，我司最终选择了 Seata，真香！ – 掘金 (juejin.cn)
TCC-Transaction原理 – 掘金 (juejin.cn)
1.原理
- 一个完整的业务活动由一个主业务服务与若干从业务服务组成。
- 主业务服务负责发起并完成整个业务活动。
- 从业务服务提供TCC型业务操作。
- 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时进行confirm操作，在业务活动取消时进行cancel操作。
TCC和2PC/3PC很像，不过TCC的事务控制都是业务代码层面的，而2PC/3PC则是资源层面的。
2.各阶段规范
TCC事务其实主要包含两个阶段：Try阶段、Confirm/Cancel阶段。
从TCC的逻辑模型上我们可以看到，TCC的核心思想是，try阶段检查并预留资源，确保在confirm阶段有资源可用，这样可以最大程度的确保confirm阶段能够执行成功。
try:尝试执行业务
- 完成所有业务检查(一致性)
- 预留必须业务资源(准隔离性)
confirm:确认执行业务
- 真正执行业务
- 不作任何业务检查
- 只使用Try阶段预留的业务资源
- Confirm操作必须保证幂等性
cancel:取消执行业务
- 释放Try阶段预留的业务资源
- Cancel操作必须保证幂等性
3.TCC优缺点
目前解决分布式事务的方案中，最稳定可靠的方案有：TCC、2PC/3PC、最终一致性。这三种方案各有优劣，有自己的适用场景。下面我们简单讨论一下TCC主要的优缺点。
TCC的主要优点:
因为Try阶段检查并预留了资源，所以confirm阶段一般都可以执行成功。
资源锁定都是在业务代码中完成，不会block住DB，可以做到对db性能无影响。
TCC的实时性较高，所有的DB写操作都集中在confirm中，写操作的结果实时返回（失败时因为定时程序执行时间的关系，略有延迟）。
TCC的主要缺点:
从源码分析中可以看到，因为事务状态管理，将产生多次DB操作，这将损耗一定的性能，并使得整个TCC事务时间拉长。
事务涉及方越多，Try、Confirm、Cancel中的代码就越复杂，可复用性就越底（这一点主要是相对最终一致性方案而言的）。另外涉及方越多，这几个阶段的处理时间越长，失败的可能性也越高。
看了 5种分布式事务方案，我司最终选择了 Seata，真香！ – 掘金 (juejin.cn)
TCC
所谓的 TCC 编程模式，也是两阶段提交的一个变种，不同的是 TCC 为在业务层编写代码实现的两阶段提交。TCC 分别指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个方法。
以下单扣库存为例，Try 阶段去占库存，Confirm 阶段则实际扣库存，如果库存扣减失败 Cancel 阶段进行回滚，释放库存。
TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常通过则 Cancel 来进行回滚补偿，这也就是常说的补偿性事务。
原本一个方法，现在却需要三个方法来支持，可以看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要考虑到网络波动等原因，为保证请求一定送达都会有重试机制，所以考虑到接口的幂等性。