分布式事务-TCC

TCC是什么

TCC 是一种补偿型事务，该模型要求应用的每个服务提供 try、confirm、cancel 三个接口，它的核心思想是通过对资源的预留(提供中间态，如账户状态、冻结金额等)，尽早释放对资源的加锁，如果事务可以提交，则完成对预留资源的确认，如果事务要回滚，则释放预留的资源。

组成

TCC模型完全交由业务实现，每个子业务都需要实现Try-Confirm-Cancel三个接口，对业务侵入大，资源锁定交由业务方。

1、Try：尝试执行业务，完成所有业务检查(一致性)，预留必要的业务资源(准隔离性)。
2、Confirm：确认执行业务，不再做业务检查。只使用Try阶段预留的业务资源，Confirm操作满足幂等性。
3、Cancel：取消执行业务释放Try阶段预留业务资源。

一个完整的业务活动由一个主业务服务与若干子业务服务组成：
1、主业务服务负责发起并完成整个业务活动
2、业务服务提供TCC型业务操作。
3、业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的Confirm操作，在业务活动取消时调用所有TCC型操作的Cancel操作。

成本

1、 实现TCC操作的成本
2、业务活动结束时Confirm或Cancel操作的执行成本。在Confirm和Cancel范围内的操作成功性需要框架来保证，只能一直重试保证资源被消耗或者释放。
3、业务活动日志成本

适用范围

1、强隔离性、严格一致性要求的业务活动
2、适用于执行时间较短的业务

应用案例

下单扣减资源

下单扣减库存

转账

A用户给B用户转账

TCC与2PC对比

TCC将事务提交划分成两个阶段，Try即为一阶段，Confirm 和 Cancel 是二阶段并行的两个分支，二选一。从阶段划分上非常像2PC，我们是否可以说TCC是一种2PC或者2PC变种呢？其实不可以，原因如下：
1、2PC的操作对象在于资源层，对于开发人员无感知；而TCC的操作在于业务层，具有较高开发成本。
2、2PC是一个整体的长事务，也是刚性事务；而TCC是一组的本地短事务，是柔性事务。
3、2PC的Prepare(表决阶段)进行了操作表决；而TCC的try并没有表决准备，直接兼备资源操作与准备能力
4、2PC是全局锁定资源，所有参与者阻塞 交互等待TM通知；而TCC的资源锁定在于Try操作，业务方可以灵活选择业务资源的锁定粒度。

TCC注意事项

TCC为了解决网络不可靠引起的异常情况，要求业务方在设计上要遵循三个策略：
1、允许空回滚：原因是异常发生在阶段一时，部分参与方没有收到 Try 请求从而触发整个事务的Cancel 操作；Try 失败或者没有执行 Try 操作的参与方收到 Cancel 请求时，要进行空回滚操作。
2、保持幂等性：原因是异常发生在阶段二时，比如网络超时，则会重复调用参与方的 Confirm/Cancel 方法，因此Confirm/Cancel方法必须保证幂等性。
3、防止资源悬挂：原因网络异常导致两个阶段无法保证严格的顺序执行，出现参与方侧 Try 请求比 Cancel 请求更晚到达的情况，Cancel 会执行空回滚而确保事务的正确性，但是此时 Try 方法也不可以再被执行。

TCC对业务的强侵入性，使用成本非常昂贵，虽然提供了更灵活的资源锁粒度，对标2PC拥有更高的吞吐量。

参考

[1] 我说分布式事务之TCC
[2] 分布式柔性事务的TCC方案