TCC事务简介

TCC事务 即：Try-Confirm-Cancel 。它是基于业务层面的事务定义，把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段的逻辑由业务代码控制。每一个初步操作，最终都会被确认或取消。因此，针对一个具体的业务服务，TCC事务机制需要业务系统提供三段业务逻辑：初步操作Try、确认操作Confirm、取消操作Cancel。

Try 从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑。TCC机制将传统事务机制中的业务逻辑一分为二，拆分后保留的部分即为初步操作（Try）；而分离出的部分即为确认操作（Confirm），被延迟到事务提交阶段执行。

• 完成所有业务检查( 一致性 )
• 预留必须业务资源( 准隔离性 )

Confirm 是对 Try 操作的一个补充。当TCC事务管理器决定commit全局事务时，就会逐个执行Try操作指定的Confirm操作，将Try未完成的事项最终完成。

Cancel 是对Try操作的一个回撤。当TCC事务管理器决定rollback全局事务时，就会逐个执行Try操作指定的Cancel操作，将Try操作已完成的事项全部撤回。

整体流程如图

TCC优缺点

• 优点：让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
• 不足：
  • 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
  • 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。

TCC-transaction

TCC-transaction 是开源的TCC补偿性分布式事务框架，使用Java实现，不和底层使用的rpc框架耦合，可以使用doubbo,thrift,web service,http等接口。事务管理器日志持久化支持多种方式，如mysql，zookeeper等。

架构

• 一个完整的业务活动由一个主业务服务与若干从业务服务组成。
• 主业务服务负责发起并完成整个业务活动。
• 从业务服务提供TCC型业务操作。
• 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时进行confirm操作，在业务活动取消时进行cancel操作。

TCC和2PC/3PC很像，不过TCC的事务控制都是业务代码层面的，而2PC/3PC则是资源层面的。

各阶段规范

TCC事务其实主要包含两个阶段：Try阶段、Confirm/Cancel阶段。 从TCC的逻辑模型上我们可以看到，TCC的核心思想是，try阶段检查并预留资源，确保在confirm阶段有资源可用，这样可以最大程度的确保confirm阶段能够执行成功。

• try:尝试执行业务

  • 完成所有业务检查(一致性)
  • 预留必须业务资源(准隔离性)

• confirm:确认执行业务

  • 真正执行业务
  • 不作任何业务检查
  • 只使用Try阶段预留的业务资源
  • Confirm操作必须保证幂等性

• cancel:取消执行业务

  • 释放Try阶段预留的业务资源
  • Cancel操作必须保证幂等性

整体流程

以下为TCC的处理流程图，他可以确保不管是在try阶段，还是在confirm/cancel阶段都可以确保数据的一致性。

从流程图上可以看到，TCC依赖于一条事务处理记录，在开始TCC事务前标记创建此记录，然后在TCC的每个环节持续更新此记录的状态，这样就可以知道事务执行到那个环节了，当一次执行失败，进行重试时同样根据此数据来确定当前阶段，并判断应该执行什么操作。

因为存在失败重试的逻辑，所以cancel、commit方法必须实现幂等。其实在分布式开发中，凡是涉及到写操作的地方都应该实现幂等。