tcc分布式事务_分布式事务解决方案之TCC

- 日理万妓 2023-01-12 10:25 161阅读 0赞

# 业务场景介绍 #

![acd47885c5a13987803cec9800323aff.png][]

public class OrderService {    // 库存服务    @Autowired    private InventoryService inventoryService;    // 积分服务    @Autowired    private CreditService creditService;    // 仓储服务    @Autowired    private WmsService wmsService;    // 对这个订单完成支付    public void pay(){        //对本地的的订单数据库修改订单状态为"已支付"        orderDAO.updateStatus(OrderStatus.PAYED);        //调用库存服务扣减库存        inventoryService.reduceStock();        //调用积分服务增加积分        creditService.addCredit();        //调用仓储服务通知发货        wmsService.saleDelivery();    }}

# TCC 实现阶段一：Try #

![c06d8e0f7a1a1dd2c023349e46213037.png][]

# TCC 实现阶段二：Confirm #

![db98fdc959924bc2f383755f22cab7ad.png][]

# TCC 实现阶段三：Cancel #

![540f6985eb2f0b73aa0c4509e0e47b99.png][]

# 总结与思考 #

你要玩 TCC 分布式事务的话：首先需要选择某种 TCC 分布式事务框架，各个服务里就会有这个 TCC 分布式事务框架在运行。然后你原本的一个接口，要改造为 3 个逻辑，Try-Confirm-Cancel：

*  先是服务调用链路依次执行 Try 逻辑。
 *  如果都正常的话，TCC 分布式事务框架推进执行 Confirm 逻辑，完成整个事务。
 *  如果某个服务的 Try 逻辑有问题，TCC 分布式事务框架感知到之后就会推进执行各个服务的 Cancel 逻辑，撤销之前执行的各种操作。

万一某个服务的 Cancel 或者 Confirm 逻辑执行一直失败怎么办呢？

TCC 事务框架会通过活动日志记录各个服务的状态。举个例子，比如发现某个服务的 Cancel 或者 Confirm 一直没成功，会不停的重试调用它的 Cancel 或者 Confirm 逻辑，务必要它成功！

最后，来看看给我们的业务，加上分布式事务之后的整个执行流程：

![600e33fd0a36dbe95fc61669ab0e5224.png][]

TCC 分布式事务框架：ByteTCC，TCC-transaction，Himly。

# 异常场景及应对机制 #

# 幂等处理 #

因为网络抖动等原因，分布式事务框架可能会**重复调用同一个分布式事务中的一个分支事务的二阶段接口**。所以分支事务的二阶段接口Confirm/Cancel需要能够保证幂等性。如果二阶段接口不能保证幂等性，则会产生严重的问题，造成资源的重复使用或者重复释放，进而导致业务故障。

# 空回滚 #

先来说定义，当没有调用参与方Try方法的情况下，就调用了二阶段的Cancel方法，Cancel方法需要有办法识别出此时Try有没有执行。如果Try还没执行，表示这个Cancel操作是无效的，即本次Cancel属于空回滚；如果Try已经执行，那么执行的是正常的回滚逻辑。

**Try方法没有执行成功，然而此时这笔分布式事务和分支事务已经落库。有两种情况会触发分布式事务的回滚：**

**1、发起方认为当前分布式事务无法成功，主动通知TC事务协调者回滚**

**2、TC事务协调者发现分布式事务超时，被动触发回滚**

# 资源悬挂 #

1.  发起方通过RPC调用参与者一阶段Try，但是发生网络阻塞导致RPC超时。
2.  RPC超时后，TC会回滚分布式事务(可能是发起方主动通知TC回滚或者是TC发现事务超时后回滚)，调用已注册的各个参与方的二阶段Cancel。
3.  参与方空回滚后，发起方对参与者的一阶段Try才开始执行，进行资源预留从而形成悬挂。

# 三种异常总结 #

前面讨论了TCC分布式事务三种典型的异常类型，它们的解决方案都依赖于一张**事务状态控制表**。我们来尝试总结一下它们各自的特点。

# 幂等 #

**问题**：TC重复调用二阶段

**解决**：事务状态控制记录作为控制手段，只有存在INIT记录时才执行，存在CONFIRMED/ROLLBACKED记录时不再执行

# 空回滚 #

**问题**：TC回滚事务调用二阶段，但一阶段尚未执行

**解决**：事务状态控制记录作为控制手段，无记录时即为空回滚

# 资源悬挂 #

**问题**：TC回滚事务调用二阶段完成空回滚后，一阶段执行成功

**解决**：事务状态控制记录作为控制手段，二阶段发现无记录时插入记录，一阶段执行时检查记录是否存在

# 共通点 #

1.  核心的解决方案就是**事务状态控制表**
2.  幂等控制作为最基础的异常处理手段；资源悬挂的前置条件是空回滚，所以发生空回滚时会插入一条状态为ROLLBACKED的控制记录。

[acd47885c5a13987803cec9800323aff.png]: /images/20221119/865019d7ab6f4dbc85f184a5cf6f1337.png
[c06d8e0f7a1a1dd2c023349e46213037.png]: /images/20221119/37b764ca91f34477ac69afa62fd8dede.png
[db98fdc959924bc2f383755f22cab7ad.png]: /images/20221119/f5e683bb020b43b38c46a0cde00fcf0a.png
[540f6985eb2f0b73aa0c4509e0e47b99.png]: /images/20221119/a89cb8edfb4742bebbc7d4a180a58680.png
[600e33fd0a36dbe95fc61669ab0e5224.png]: /images/20221119/8979c4bbb1fc4c3ba2334e01fe55f675.png