分布式事务 之 TCC

分布式事务 之 TCC

 

 

 

1、简介

     前面我们讲了2PC、3PC 都是基于数据库的XA协议实现的分布式事务， 接下来我们介绍TCC方案，应用层面的解决方案。TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的 操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel 操作若执行失败，TM会进行重试。TCC是最终一致性的解决方案。

成功的情况：

 失败的情况：

 

2、TCC分为三个阶段：

1. Try： 是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。
2. Confirm： 是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。
3. Cancel： 是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

 

3、落地实现TCC

这里以1、下订单， 2、减库存、3、生成用户积分为例：

3.1、TCC - try 阶段

 1、保存订单时， 给订单一个中间状态， 比如下单中， 这个状态只是用来做分布式事务处理， 和业务中的订单状态无关。

 2、比如库存总量是100， 下单2件商品， 这时库存总量修改成 98，然后在一个单独的冻结库存的字段里，设置一个2。也就是说，有2个库存是给冻结了。

 3、别直接给用户增加会员积分。你可以先在积分表里的一个预增加积分字段加入积分。

3.2、TCC - Confirm阶段

 1、这个时候修改订单的状态为下单成功。

 2、Confirm逻辑，这里就是将之前冻结库存字段的2个库存扣掉变为0。

 3、将预增加字段的10个积分扣掉，然后加入实际的会员积分字段中，从1190变为1120。

3、TCC-Cancel阶段

 1、这个时候修改订单的状态为下单失败。

 2、将冻结库存扣减掉2，加回到可销售库存里去，98 + 2 = 100。

 3、将预增加积分字段的10个积分扣减掉。

小总结：

可以看出TCC方案对业务的入侵比较大， 平时1个接口就能写完的， 现在好了需要实现 try、confirm、cancel3个接口，当然实现这3个接口的驱动一般是使用开源的框架实现。

 

4、开源的TCC解决方案

目前市面上的TCC框架众多比如下面这几种：

框架名称	Gitbub地址
tcc-transaction	https://github.com/changmingxie/tcc-transaction
Hmily	https://github.com/yu199195/hmily
ByteTCC	https://github.com/liuyangming/ByteTCC
EasyTransaction	https://github.com/QNJR-GROUP/EasyTransaction

Hmily官网介绍：https://dromara.org/website/zh-cn/docs/hmily/index.html

 

5、TCC需要注意三种异常处理分别是：空回滚、幂等、悬挂

5.1、空回滚：

      在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。

      解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

5.2、幂等：

     通过前面介绍已经了解到，为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。解决思路在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。

5.3、悬挂：

       悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵， 通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支 事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

 

6、TCC优缺点

• 优势：TCC执行的每一阶段都会提交本地事务并释放锁，并不需要等待其他事务的执行结果。而如果其他事务执行失败，最后不是回滚，而是执行补偿操作。这样就避免了资源的长期锁定和阻塞等待，执行效率比较高，属于性能比较好的分布式事务方式。

• 缺点：

  • 代码侵入：需要编写代码实现 try 、confirm、 cancel 代码侵入较多。
  • 开发成本高：一个业务需要拆分成 3个步骤，分别编写业务实现，业务编写比较复杂。
  • 安全性考虑：cancel 动作如果执行失败，资源就无法释放，需要引入重试机制，而重试导致重复执行哦，还有考虑重试的幂等性问题。