不喜欢分布式中的TCC模式了

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

TCC回顾

TCC到底是什么呢?

以经典的电商系统来说，客户购买一件商品，系统需要3个服务来协作完成。订单服务增加订单，库存服务扣减库存，账户服务扣减金额。如下图：如果我们用上图的方式，每个服务各自提交事务，很有可能会出现数据不一致的情况。因为3个服务使用不同数据库，并不是一个原子操作，比如订单服务提交成功而账户服务失败了，这样数据就不一致了。

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

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!