分布式之分布式事务V2

写在前面

本文一起来看下分布式环境下的事务问题，即我们经常听到的分布式事务问题。想要解决分布式事务问题，需要使用到分布式事务相关的协议，主要有2PC即两阶段提交协议，TCC（try-confirm-cancel），接下来我们一起看下吧！

1：两阶段提交协议

该协议需要两类角色：

协调者Coordinator：负责协调工作
节点（有多个）：负责数据的处理

这里的两阶段分别是投票阶段和完成阶段，在投票阶段，协调者会询问所有的节点是否能够提交事务（简单起见，假设一切正常），然后节点返回可正常提交事务（注意一旦返回协调者自己可以提交事务，则无论是节点重启还是其他情况都要保证后续能够提交，即这一阶段相关的状态是需要持久化），协调者汇总后，发现所有节点都可正常完成事务，则进入完成阶段，向所有节点发送提交事务消息，所有节点完成事务提交。

这里我们假定协调名称是Coco，有三个节点分别是Node1，Node2，Node3，则该过程如下：

协调者在收到所有的确定回复后，进入完成阶段，向所有节点发送提交事务消息，所有事务完成事务提交后，回复事务成功消息给协调者，如下图：

以上程序实现参考这里 ，运行效果如下：

2PC存在问题如下:

1：投票阶段到提交阶段这段时间，资源是锁定的，会影响并发度，且等待过程是阻塞的
2：需要基于数据库来实现，所以如果业务上需要定制的话，修改的成本高，难度大（毕竟修改数据库的，如MySQL的源码还不是很容易的）

如果因为上述两个问题，不适合你的业务的话，则可以考虑使用TCC，不同于2PC，TCC是基于业务代码来实现分布式事务的，接下来看下TCC。

2：TCC

全称try-confirm-cancel，类似于2PC，也是两个阶段，但是是预留阶段和确认阶段，如下图：

可以看到和2PC比较类似，但确认阶段之前，因为是在业务层实现，所以不会真正的锁定数据库的资源，而只是记录必要的操作，等到确认阶段再来真正执行这些操作（预留阶段记录要做的操作，确认阶段调用数据库具体执行这个过程是我个人的猜测，不一定准确！），该过程源码实现参考这里 ，运行过程如下图：

写在后面

小结

本文分析了分布式事务的协议2PC，TCC，分析了其大概的内容，并通过代码的方式实现了其过程。希望本文能够帮助到你。

多指导一点

3PC是在2PC的基础上解决了无限等待的问题，同时增加了一次预提交的交互，但是这种方式会使交互的次数增多，导致性能降低，所以在实际场景中应用的并不多的。

参考文章列表