分布式解决方案之TCC

概述

什么是TCC事务

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

TCC分为三个阶段：

1. Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。
2. Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即：只有Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。
3. Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
4. TM事务管理
   TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。
   TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于Confirm和Cancel失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同。

TCC解决方案

目前市面上的TCC框架众多比如下面这几种：
（以下数据采集日为2019年07月11日）
tcc-transaction：https://github.com/changmingxie/tcc-transaction
Hmily：https://github.com/dromara/hmily
ByteTCC：https://github.com/liuyangming/ByteTC
EasyTransaction：https://github.com/QNJR-GROUP/EasyTransaction
上一节所讲的Seata也支持TCC，但Seata的TCC模式配置相对复杂。我们的目标是理解TCC的原理以及事务协调运作的过程，因此更倾向于轻量级易于理解的框架，因此最终确定了Hmily。
Hmily是一个高性能分布式事务TCC开源框架。基于Java语言来开发（JDK1.8），支持Dubbo，Spring Cloud等RPC框架进行分布式事务。它目前支持以下特性：

• 支持嵌套事务（Nested transaction support）。
• 采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别。
• 支持SpringBoot-starter项目启动，使用简单。
• RPC框架支持：dubbo，motan，springCloud。
• 本地事务存储支持：redis，mongodb，zookeeper，file，mysql。
• 事务日志序列化支持：java，hessian，kryo，protostuff。
• 采用Aspect AOP切面思想与Spring无缝集成，天然支持集群。
• RPC事务恢复，超时异常恢复等。
  Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，通过多方拦截，事务参与者能透明的调用到另一方的Try、Confirm、Cancel方法；传递事务上下文；并记录事务日志，酌情进行补偿，重试等。
  Hmily不需要事务协调服务，但需要提供一个数据库（mysql/mongodb/zookeeper/redis/file）来进行日志存储。
  Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。Confirm/cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Confirm/Cancel业务只需要被Hmily TCC事务框架发现即可。不需要被调用它的其他业务服务所感知。
  官网介绍：https://dromara.org/website/zh-cn/docs/hmily/index.html

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂

空回滚

幂等

悬挂