分布式事物－学习笔记－解决方案之TCC(补偿事务)

1 TCC事务概述

TCC(Try/Confirm/Cancel)编程模式的核心思想是：针对每个分支事务操作，都要向全局事务发起方注 册Try、Confirm和Cancel三个操作，具体这些操作由我们自己根据业务进行实现，然后分为两个阶段去 执行：

1. Try 阶段主要是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。

2. Confirm 阶段主要是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况 下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若 Confirm阶段真的出错了，需引入重试机制或人工处理。

3. Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行分支事务的业务取消，预留资源释 放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

 

案例1： A转账30元给B，A账户和B账户在不同银行(服务)，当前余额都为100元

 

 

 我们需要把之前实现的转账的代码拆分成三块，套到try-confirm-cancel中，由事务管理器(协调管理)推 进AB两个try分别执行，在这个过程中，事务管理器会对AB进行监控，一旦任何一方出现了问题，就推 进对方执行cancel；如果双方都没有异常，就推进AB执行confirm。如果在执行confirm或cancel过程 中出现问题，就引入重试机制或由人工处理。

TCC解决方案要求每个分支事务实现三个操作Try/Confirm/Cancel。try操作做业务检查及资源预留， Confirm操作做业务确认操作，Cancel操作需要实现一个与try相反的操作。TM(事务管理器)首先发起所 有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操 作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行 框架名称 Gitbub地址 tcc-transaction https://github.com/changmingxie/tcc-transaction Hmily https://github.com/yu199195/hmily ByteTCC https://github.com/liuyangming/ByteTCC EasyTransaction https://github.com/QNJR-GROUP/EasyTransaction 失败，TM会进行重试，因此需要实现幂等。Try/Confirm/Cancel这三个操作的具体实现，由开发者根 据业务情况灵活掌握。

TCC不足之处：

• 　　对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性 较强，改造成本高。
• 　　实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一 致性的要求，confirm和cancel接口必须实现幂等。

２ TCC框架

目前市面上的TCC框架众多比如下面这几种：

框架名称　 　　Gitbub地址

tcc-transaction 　https://github.com/changmingxie/tcc-transaction

Hmily　　　　　 https://github.com/yu199195/hmily

ByteTCC 　　　https://github.com/liuyangming/ByteTCC

EasyTransaction https://github.com/QNJR-GROUP/EasyTransaction

Hmily是一个高性能分布式事务tcc开源框架。基于java语言来开发（JDK1.8），支持dubbo， springcloud，motan等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对参与分布式事务的本地方法与远程方

Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，通过多方拦截，事务参与者能 透明的调用到另一方的Try、Conform、Cancel方法；传递事务上下文；并记录事务日志，酌情进行补 偿，重试等。

Hmily不需要事务协调服务，但需要提供一个数据库(mysql/mongodb/zookeeper/redis/file)来进行日 志存储。Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。 Confirm/Cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Confirm/Cancel业务只 需要被Hmily事务框架发现即可，不需要被调用它的其他业务服务所感知。

官网介绍：https://dromara.org/website/zh-cn/docs/hmily/index.html