一文彻底搞懂分布式事务

引子

在分布式系统中，由于业务的划分导致了原本单机系统本地完成的事务被分割在了不同的微服务中，这也带来了分布式情况下事务如何解决？如何保证不同微服务之间的事务保持原子性？一致性？隔离性？持久性？那么分布式事务有哪些已经成熟的解决方案呢？下面我们来一起看看。

2pc: 两阶段提交协议。

首先来看2pc的概念：  这是一个简单的两阶段提交协议的分布式事务。通过一个事务协调器，在prepare 阶段询问所有分布式事务参与者是否已经准备就绪。然后在commit/roolback阶段发起真正的提交或回滚，从而完成一次分布式事务。

接下来我们来看2pc的流程图，具体来解析下2pc如何处理的。此过程 涉及的参与方： 协调者，参与者。采用了cap原理中的 cp 。cap: 分布式理论的一个概念，简单介绍下： CAP : 一致性，可用性，分区容忍性。在任何一个分布式系统中都不可避免会遇到p,即系统之间网络故障，导致不通。即发生了分区，此时我们只能在C和A中选择一个，这就是著名的CAP理论。

• 通过上图我们可以得到如下结论：
• 优点： 方案成熟，处理过程简单清晰。强一致性。
• 缺点： 阻塞，如果任何一个参与者挂了，则其他参与者都是处于一直阻塞等待状态。commit，rollback 无法确保都会到达所有参与者。可能由于网络等原因导致，这样只有部分参与者收到commit信息，导致数据不一致。
• 问题：
• 单点问题： 协调者挂了。可以适用主备模式，防止单点。协调者挂了选举从切换为主协调者。
• 参与者挂了： 协调者收不到参与者的响应，可以设置超时机制。超时了则认为返回NO，则想所有参与者发送rollback,防止其他参与者一直等待。也可以加入重试机制，超时重试几次后，才认为其返回为No。这样保持了强一致性。
• 部分提交： 只有一部分参与者收到提交回滚消息。导致数据不一致。这里可以加入确认机制，确认参与者实现了自己的事务提交，没有收到确认信息的采用补偿机制进行重试。达到数据的最终一致性。
• 适应场景： 需要保持分布式事务强一致性的场景。比如订单和账户扣款服务。双方服务高可用。

 3pc:   三阶段提交协议，解决2pc的阻塞问题。分为canCommit,prepareCommit,doCommit.

多加了一层cancommit，询问参与者是否能完成自己的事务。获取数据库锁。其他的和2pc一样，准备阶段一分为2，为在事务真正提交回滚前，各个参与者到达一致性状态提供了保障。

• canCommit： 这一阶段协调者向参与者询问是否可以预提交事务，得到所有的参与者回复Yes，则进入prepareCommit阶段。
• prepareCommit： 这一阶段和2pc的prepare阶段大致一样。不一样的地方在于，参与者有了超时机制，即协调者和参与者都有了超时机制。在任何一方挂掉的情况下，另一方不会傻傻的一直等待响应了。这也是防止了一直阻塞的情况。
• doCommit: 和2pc 的第二阶段一样。

TCC： 基于2pc 改进的基于补偿实现的分布式事务解决方案。

tcc 分为三个阶段，try阶段，confirm阶段，cancel阶段。通过对每一步操作的添加的确认或撤销操作，从而实现即失败异常时的补偿机制。达到数据一致性的目的。

try阶段：检查参与者是否满足业务条件，可以继续向下走。比如 转账时对账户及其余额的检查，对收款方账户的检查。

confirm: try阶段成功后，通过confirm对参与方进行事务提交。try成功，则confirm一定成功。

cancel： try失败了或有异常，则取消之前参与方对资源的锁定，或者回滚已经处理的业务。

那么现实中采用的流行的解决方案是哪些呢？让我们一起来看下ebay 提供的本地消息表的解决方案，还有分布式事务消息的解决方案，具体的场景不同，我们可以选择不同的方案。当然，最大程度避免使用分布式事务自然最好。

ebay本地消息表分布式事务解决方案。

本地消息表的思想是： 通过将分布式事务的分解为一个个本地事务，通过消息来串联起一个个本地事务，来达到实现分布式事务的目的。这样可以基于mysql这样的关系数据库来实现。 我们来看下流程图：

 

• 本地消息表的实现方式，整体看来比较清晰简单。本地事务的可靠性，保证了消息写入的可靠。并且可以利用MQ的高可用，时效高，削峰等特性，可以看到效果是不错的。目前有去哪儿，支付宝，蘑菇街等知名互联网公司在使用。也给我们提供了一个参考。