我有点不喜欢分布式中的TCC模式了

作者： jinjunzhu 2021-03-01 08:35:23

开发

前端

分布式 分布式事务的解决方案中，TCC是比较经典的模式，使用2阶段提交的思想来实现分布式事务的最终一致。但最近我有点不喜欢TCC模式了。

[[384133]]

本文转载自微信公众号「程序员jinjunzhu」，作者jinjunzhu 。转载本文请联系程序员jinjunzhu公众号。

分布式事务的解决方案中，TCC是比较经典的模式，使用2阶段提交的思想来实现分布式事务的最终一致。但最近我有点不喜欢TCC模式了。

TCC回顾

TCC到底是什么呢?

以经典的电商系统来说，客户购买一件商品，系统需要3个服务来协作完成。订单服务增加订单，库存服务扣减库存，账户服务扣减金额。如下图：

如果我们用上图的方式，每个服务各自提交事务，很有可能会出现数据不一致的情况。因为3个服务使用不同数据库，并不是一个原子操作，比如订单服务提交成功而账户服务失败了，这样数据就不一致了。

TCC的思想是使用2阶段提交，try阶段首先尝试各个服务预留资源，如果预留成功则进入commit阶段提交事务，如果有一个服务预留失败，那就进入cancel阶段取消事务。这需要加入一个协调节点来对3个服务下发命令并且获取每个服务的分支事务执行结果。try阶段用下图表示：

try阶段如果各个服务预留资源成功，协调节点就会对各服务下发commit命令，如下图：

所有服务commit成功后，整个事务完成。

代码实现

协调节点需要给每个分布式事务提供一个全局事务id，叫做xid，用来跟每个服务的本地事务绑定。我们以账户服务为例，来看一下try/commit/cancel这3个阶段的代码：

这段代码使用了jdbc来处理本地事务，try阶段我们获取了connection并且保存在connectionMap，key是xid，这样在commit/cancel阶段，从connectionMap中取出connection来commit/rollback。

存在问题

上面TCC模式的代码实现有问题吗?

服务集群

如下图，如果订单服务集群部署在3个机器上，try请求发送到订单服务1，而commit请求发到订单服务2上，订单服务2的connectionMap怎么可能有xid=123的这个值呢?订单服务本地事务不能提交了。

所以如果真要用保持connection的方式来提交事务，协调节点就需要保证同一个xid对应的try/commit/cancel请求到同一个机器上。

解决方案肯定有，改造注册中心，或者协调节点自己维护服务列表。前者让注册中心耦合了业务代码，后者相当于废弃了注册中心。

空提交

注册中心和协调节点的改造都需要很大的工作量，有没有别的方法呢?我们做一个改进，这里orm框架使用mybatis，代码如下：

try阶段要预留资源，这段代码如果预留资源成功，其实已经提交分支事务了，commit阶段只是一个空提交，没有实际作用了。

还有一种方式就是try阶段直接返回true，到commit阶段真正提交事务。

但是这两种方式都违背了TCC的思想。

幂等

如果协调节点设置了超时重试，发生了下图的情况，订单服务1执行完try方法后发生故障，协调节点收不到成功回复必定会进行重试，这样订单服务就会重复执行try方法。

为了规避这个问题，try/confirm/cancel方法都必须加入幂等逻辑，记录全局事务xid对应本地事务的执行状态。

空回滚

使用框架来实现TCC模式时，会有一种空回滚的情况。

如上图，因为订单服务1节点故障，try方法失败，但是全局事务已经开启，框架必须要把这个全局事务推向结束状态，这样就不得不调用订单服务cancel方法进行回滚，结果订单服务空跑了一次cancel方法。

解决这个问题，try阶段需要记录xid对应的分支事务执行状态，cancel阶段根据这个记录来进行判断。

悬挂

上面讲了seata的使用过程中会发生空回滚，如果发生了空回滚，执行了cancel方法后全局事务结束了，但是因为网络问题，订单服务又收到了try请求，执行try方法后预留资源成功，这些资源却不能释放了。

解决这个问题的方法就是在cancel方法中记录xid对应的分支事务执行状态，try阶段执行的时候先判断分支事务是否已经回滚。

代码侵入高

TCC的try/commit/cancel，对业务代码都有侵入，如果再考虑幂等、空回滚、悬挂等，代码侵入会更高。

总结

TCC是分布式事务中非常经典的模式，但即使借助框架实现，代码实现也比较复杂。

实际使用时需要考虑服务集群、空提交、幂等、空回滚、悬挂等问题。

对业务代码侵入性很高。