分布式事务TCC

分布式事务TCC

概念

TCC（Try-Confirm-Cancel）是一种事务模型，其概念源自于Pat Helland的论文《Life beyond Distributed Transactions:an Apostate’s Opinion》。

TCC提出了一种基于业务层面的事务定义方式，通过由业务自身控制锁粒度，解决了复杂业务中跨表跨库等大颗粒度资源锁定的问题。

TCC将事务过程分为Try（尝试）、Confirm（确认）和Cancel（取消）三个阶段，每个阶段由业务代码控制，避免了长事务的问题，从而提高了性能。
TCC 的具体流程如下图所示：

Try阶段：尝试执行业务并完成所有业务检查，预留业务资源。

Confirm和Cancel阶段：这两个操作是互斥的，只可以选择其中一个。

Confirm操作是确认提交，执行业务操作，不进行其他业务检查，只使用Try阶段预留的业务资源。

Cancel操作在业务执行错误需要回滚的情况下执行，释放预留的资源。

Try 阶段失败可以 Cancel，如果 Confirm 和 Cancel 阶段失败了呢？

TCC事务模型中会使用事务日志来记录Try、Confirm和Cancel阶段的操作。如果在Confirm或Cancel阶段发生错误，系统会进行重试操作。因此，这两个阶段需要支持幂等性，以确保多次执行的结果与一次执行的结果相同。如果重试操作失败，就需要人工介入来进行恢复和处理。

TCC 的优缺点：

TCC（Try-Confirm-Cancel）是一种分布式事务解决方案，其本质是将数据库的二阶段提交协议上升到微服务层面，以避免长事务带来的性能风险。

TCC解决了跨服务的业务操作原子性问题，例如下订单减库存、多渠道组合支付等场景。通过将业务拆解成try、confirm、cancel三个操作，应用程序可以自定义数据库操作的粒度，从而降低锁冲突，提高系统的业务吞吐量。

然而，TCC也存在一些不足之处。首先，TCC对微服务的侵入性较强，需要对业务系统进行改造，每个分支的业务逻辑都需要实现try、confirm和cancel操作，并且confirm和cancel操作必须保证幂等性。

此外，TCC的事务管理器需要记录事务日志，这也会带来一定的性能损耗。

Hmily 实现

概述

Hmily是一个高性能分布式事务TCC开源框架。基于Java语言来开发（JDK1.8），支持Dubbo，Spring Cloud等RPC框架进行分布式事务。它目前支持以下特性：

(1) 支持嵌套事务 (Nested transaction support).
(2) 采用 disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别。
(3) 支持 SpringBoot-starter 项目启动，使用简单。
(4) RPC 框架支持 : dubbo,motan,springcloud。
(5) 本地事务存储支持 : redis,mongodb,zookeeper,file,mysql。
(6) 事务日志序列化支持 ：java，hessian，kryo，protostuff。
(7) 采用 Aspect AOP 切面思想与Spring无缝集成，天然支持集群。
(8) RPC 事务恢复，超时异常恢复等。

Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，通过多方拦截，事务参与者能透明的调用到另一方的Try、Confirm、Cancel方法；传递事务上下文；并记录事务日志，酌情进行补偿，重试等。Hmily 不需要事务协调服务，但需要提供一个数据库(mysql/mongodb/zookeeper/redis/file)来进行日志存储。

Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。Confirm/Cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Confirm/Cancel业务只需要被Hmily TCC事务框架发现即可，不需要被调用它的其他业务服务所感知。