转：分布式事务之TCC服务设计和实现注意事项

 由公司微服务培训引起的一丢丢对TCC的好奇

 

 

 原文：https://yq.aliyun.com/articles/609854

 

一、TCC简介

TCC是一种比较成熟的分布式事务解决方案，可用于解决跨库操作的数据一致性问题；

TCC是服务化的两阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现；

其中Try操作作为一阶段，负责资源的检查和预留，Confirm操作作为二阶段提交操作，执行真正的业务，Cancel是预留资源的取消；

 

 

 

如下图所示，接入TCC前，业务操作只需要一步就能完成，但是在接入TCC之后，需要考虑如何将其分成2阶段完成，把资源的检查和预留放在一阶段的Try操作中进行，把真正的业务操作的执行放在二阶段的Confirm操作中进行；

 

如下图所示，事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因为丢包而导致的网络超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；

TCC服务在未收到Try请求的情况下收到Cancel请求，这种场景被称为空回滚；TCC服务在实现时应当允许空回滚的执行；

 

如下图所示，事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因网络拥堵而导致的超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；在此之后，拥堵在网络上的一阶段Try数据包被TCC服务收到，出现了二阶段Cancel请求比一阶段Try请求先执行的情况；

用户在实现TCC服务时，应当允许空回滚，但是要拒绝执行空回滚之后到来的一阶段Try请求，即防悬挂控制

 

 

 

无论是网络数据包重传，还是异常事务的补偿执行，都会导致TCC服务的Try、Confirm或者Cancel操作被重复执行；用户在实现TCC服务时，需要考虑幂等控制，即Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的；

 

更多了解，请查看原文：https://yq.aliyun.com/articles/609854

 

 TCC 事务应用场景

我们通过用户下单使用余额+红包支付来看一下TCC事务的具体应用。
假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统，下单成功需要同时调用资金账户服务和红包服务完成支付
假设购买商品1000元，使用账户红包200元，余额800元，确认支付。
Try操作
tryX 下单系统创建待支付订单
tryY 冻结账户红包200元
tryZ 冻结资金账户800元
Confirm操作
confirmX 订单更新为支付成功
confirmY 扣减账户红包200元
confirmZ 扣减资金账户800元
Cancel操作
cancelX 订单处理异常，资金红包退回，订单支付失败
cancelY 冻结红包失败，账户余额退回，订单支付失败
cancelZ 冻结余额失败，账户红包退回，订单支付失败