@transaction 提交事务_分布式事务 TCC-Transaction 源码分析——TCC 实现

1. 概述

本文分享 TCC 实现。主要涉及如下三个 Maven 项目：

• tcc-transaction-core ：tcc-transaction 底层实现。
• tcc-transaction-api ：tcc-transaction 使用 API。
• tcc-transaction-spring ：tcc-transaction Spring 支持。

你行好事会因为得到赞赏而愉悦同理，开源项目贡献者会因为 Star 而更加有动力为 TCC-Transaction 点赞！传送门

OK，开始我们的第一段 TCC 旅程吧。

ps：笔者假设你已经阅读过《tcc-transaction 官方文档 —— 使用指南1.2.x》。

ps2：未特殊说明的情况下，本文事务指的是 TCC事务。

2. TCC 原理

TCC事务为了解决在事务运行过程中大颗粒度资源锁定的问题，业界提出一种新的事务模型，它是基于 业务层面的事务定义。锁粒度完全由业务自己控制。它本质是一种补偿的思路。它把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段的逻辑由 业务代码控制。这样就事务的锁粒度可以完全自由控制。业务可以在牺牲隔离性的情况下，获取更高的性能。

• Try 阶段
• 完成所有业务检查( 一致性 )
• 预留必须业务资源( 准隔离性 )
• Try ：尝试执行业务
• Confirm / Cancel 阶段：
• 释放 Try 阶段预留的业务资源
• Cancel 操作满足幂等性
• 真正执行业务
• 不做任务业务检查
• Confirm 操作满足幂等性
• Confirm ：确认执行业务
• Cancel ：取消执行业务
• Confirm 与 Cancel 互斥

整体流程如下图：

• 红框部分功能由 tcc-transaction-core 实现：
• 启动业务活动
• 登记业务操作
• 提交 / 回滚业务活动
• 黄框部分功能由 tcc-transaction-http-sample 实现( 官方提供的示例项目 )：
• Try 操作
• Confirm 操作
• Cancel 操作

与 2PC协议 比较：

• 位于业务服务层而非自愿层
• 没有单独的准备( Prepare )阶段，Try 操作兼备自愿操作与准备能力
• Try 操作可以灵活选择业务资源的锁定粒度
• 较高开发成本

参考资料：

• 《支付宝运营架构中柔性事务指的是什么？》
• 《分布式事务的典型处理方式:2PC、TCC、异步确保和最大努力型》

3. TCC-Transaction 原理

在 TCC 里，一个业务活动可以有多个事务，每个业务操作归属于不同的事务，即一个事务可以包含多个业务操作。TCC-Transaction 将每个业务操作抽象成事务参与者，每个事务可以包含多个参与者。

参与者需要声明 try / confirm / cancel 三个类型的方法，和 TCC 的操作一一对应。在程序里，通过 @Compensable 注解标记在 try 方法上，并填写对应的 confirm / cancel 方法，示例代码如下：

// try

@Compensable(confirmMethod = "confirmRecord