Seata TCC 模式理论学习、生产级使用示例搭建及注意事项 | Spring Cloud55

前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站，这篇文章男女通用，看懂了就去分享给你的码吧。Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。在 Seata 开源之前，Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。经过多年沉淀与积累，商业化产品先后在阿里云、金融云进行售卖。

Seata TCC模式实战

Seata TCC模式详解：通过Try-Confirm-Cancel三阶段实现分布式事务。Try阶段预留资源并检查业务规则（如库存检查），Confirm阶段确认业务操作（订单支付），Cancel阶段执行补偿（恢复库存）。实现要点包括幂等性设计、业务状态管理和异常处理。Java示例展示了订单服务接口及实现，通过@GlobalTransactional注解开启全局事务。TCC模式适合复杂业务场景，需遵循Try轻量化、状态机管理和异常捕获等最佳实践。虽然实现复杂，但提供了事务控制的灵活性。

TCC 是分布式事务中的二阶段提交协议，它的全称为 Try-Confirm-Cancel，即资源预留（Try）、确认操作（Confirm）、取消操作（Cancel），他们的具体含义如下： Try：对业务资源的检查并预留。 Confirm：对业务处理进行提交，即 commit 操作，只要 Try 成功，那么该步骤一定成功。 Cancel：对业务处理进行取消，即回滚操作，该步骤回对 Try 预留的资源进行释放。 TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的

什是TCC模式 TCC模式可以理解成基于业务的二阶段提交模型，它不不依赖于底层数据资源的事务支持，需要开发者自定义以下3种行为代码逻辑，分别是： 一阶段 prepare 行为：调用自定义的 prepare 逻辑。 二阶段 commit 行为：调用自定义的 commit 逻辑。 二阶段 rollback 行为：调用自定义的 rollback 逻辑。 接着把以上自定义的分支事务纳入到全局事务的管理中。 Seata实现TCC 安装好seata服务端。 由于TCC模式不用基于数据库来控制事务，所以demo项目

TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。第一阶段：Try（尝试），主要是对业务系统做检测及资源预留(加锁，锁住资源)第二阶段：本阶段根据第一阶段的结果，决定是执行confirm还是cancelConfirm（确认）：执行真正的业务（执行业务，释放锁）Cancle（取消）：是预留资源的取消（出问题，释放锁）

TCC 模式是分布式事务使用最多的模式，但是幂等、悬挂和空回滚一直是 TCC 模式需要考虑的问题。Seata 框架在 1.5.1 版本完美解决了这些问题。

一、前提 基于支持本地 ACID 事务的关系型数据库。 Java 应用，通过 JDBC 访问数据库。 二、整体机制 两阶段提交协议的演变： 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。 二阶段： 提交异步化，非常快速地完成。 回滚通过一阶段的回滚日志进行反向补偿。

Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行Confirm方法，二阶段回滚执行 Cancel 方法。TCC 三个方法描述：业务模型分 2 阶段设计：用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；

本文主要介绍了分布式事务中的TCC模式，对比了Seata中AT模式和TCC模式的区别及适用场景，文中附有Seata中使用TCC模式的示例代码及代码仓库地址，并简要介绍了TCC中的幂等、空回滚、悬挂三大问题及Seata1.5中给出的解决方案。

当前 Seata-go 的 XA 模式支持 MySQL 数据库。Seata 社区近期与不少国内 Go 语言微服务框架以及 ORM 框架背后的开发社区达成合作，比如 GORM 框架，已经集成到了 Sample 中，后续会将更多的 ORM 框架集成在 Seata-go-samples 项目中。Seata-go-samples 集成到 Seata-go GitHub Actions 的集成测试环境，目前已经在进行中，用于测试每个 PR，保证系统的兼容性与稳定性。

分布式事务解决方案

TCC 模式是一种侵入式的分布式事务解决方案，它不依赖于数据库的事务，而是要求开发者自定义完成 预提交、提交、回滚的方法逻辑。因此，它是一个种偏复杂、灵活、有侵入性的分布式事务处理方案。

概括来看，该模式有以下几个特点:该模式对代码的嵌入性高，开发工作较多，要求每个业务需要写TCC三步骤的操作。无论有没有本地事务控制都可以使用该模式，与底层数据库事务实现不相关，这个事务模式是抽象的基于服务层的概念，无论DB层是否有JDBC支持，即使没有JDBC的支持如redis、mongo、es等，只要将对他们的操作包装成TCC的参与者，就可以接入到TCC的事务范围内。并发度高，无需长期资源锁定，但并发问题、数据的一致性问题，需由开发者自行根据业务场景控制，开发要求高、难度偏大。

TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC分为两个阶段，分别如下：第一阶段：Try（尝试），主要是对业务系统做检测及资源预留 (加锁，锁住资源)第二阶段：本阶段根据第一阶段的结果，决定是执行confirm还是cancelConfirm（确认）：执行真正的业务（执行业务，释放锁）Cancle（取消）：是预留资源的取消（出问题，释放锁）

此外，还需要一个 Seata Server 来协调分布式事务。中定义 Try、Confirm 和 Cancel 方法。中定义 Try、Confirm 和 Cancel 方法。