实战！阿里神器 Seata 实现 TCC模式 解决分布式事务，真香（一）

大家好，我是不才陈某~

这是《Spring Cloud 进阶》第19篇文章，往期文章如下：

• 五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？
• openFeign夺命连环9问，这谁受得了？
• 阿里面试这样问：Nacos、Apollo、Config配置中心如何选型？这10个维度告诉你！
• 阿里面试败北：5种微服务注册中心如何选型？这几个维度告诉你！
• 阿里限流神器Sentinel夺命连环 17 问？
• 对比7种分布式事务方案，还是偏爱阿里开源的Seata，真香！(原理+实战)
• Spring Cloud Gateway夺命连环10问？
• Spring Cloud Gateway 整合阿里 Sentinel网关限流实战！
• 分布式链路追踪之Spring Cloud Sleuth夺命连环9问？
• 链路追踪自从用了SkyWalking，睡的真香！
• 3本书了，7万+字，10篇文章，《Spring Cloud 进阶》基础版 PDF
• 妹子始终没搞懂OAuth2.0，今天整合Spring Cloud Security 一次说明白！
• OAuth2.0实战！使用JWT令牌认证！
• OAuth2.0实战！玩转认证、资源服务异常自定义这些骚操作！
• 实战干货！Spring Cloud Gateway 整合 OAuth2.0 实现分布式统一认证授权！
• 字节面试这样问：跨库多表存在大量数据依赖问题有哪些解决方案？
• 实战！退出登录时如何借助外力使JWT令牌失效？
• 实战！Spring Cloud Gateway集成 RBAC 权限模型实现动态权限控制！

今天这篇文章介绍一下Seata如何实现TCC事务模式，文章目录如下：

 目录

什么是TCC模式？
TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

TCC分为两个阶段，分别如下：

• 第一阶段：Try（尝试），主要是对业务系统做检测及资源预留 (加锁，锁住资源)
• 第二阶段：本阶段根据第一阶段的结果，决定是执行confirm还是cancel
  1.Confirm（确认）：执行真正的业务（执行业务，释放锁）
  2.Cancle（取消）：是预留资源的取消（出问题，释放锁）

 TCC

为了方便理解，下面以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤，库存服务和订单服务分别在不同的服务器节点上。

假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。

①Try 阶段
TCC 机制中的 Try 仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

• 完成所有业务检查( 一致性 ) 。
• 预留必须业务资源( 准隔离性 ) 。
• Try 尝试执行业务。

 Try阶段

②Confirm / Cancel 阶段
根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。

Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。

Confirm：当 Try 阶段服务全部正常执行， 执行确认业务逻辑操作，业务如下图：

 Try->Confirm

这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。

Confirm 阶段也可以看成是对 Try 阶段的一个补充，Try+Confirm 一起组成了一个完整的业务逻辑。

Cancel：当 Try 阶段存在服务执行失败， 进入 Cancel 阶段，业务如下图：

 Try-Cancel

Cancel 取消执行，释放 Try 阶段预留的业务资源，上面的例子中，Cancel 操作会把冻结的库存释放，并更新订单状态为取消。

以上便是TCC模式的全部概念，这部分内容在陈某之前的文章也是详细的介绍过：对比7种分布式事务方案，还是偏爱阿里开源的Seata，真香！(原理+实战)

文章转自公众号：码猿技术专栏