分布式事务及解决方案(2PC、3PC、TCC事务补偿、本地消息表)

1. 简述

分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。

在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲，两台机器理论上无法达到一致的状态。如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。

2PC 和 3PC 都是DB(数据库)层面的，而 TCC 是业务层面的分布式事务，就像我前面说的分布式事务不仅仅包括数据库的操作，还包括发送短信等

2 两阶段提交（2PC）

2.1 准备阶段

协调者询问参与者事务是否执行成功，参与者发回事务执行结果，左侧是步骤1，询问是否准备好了，右侧是步骤2，返回是否准备好了：

假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败，完整的流程如下：

数字1、2、3分别代表步骤1、2、3，其中步骤3是在步骤2结束后，汇总结果，发现有一个失败的，那么全部就要回滚。

2.2 提交阶段

如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。

需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

2.3 存在的问题

1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。

2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。

首先 2PC 是一个同步阻塞协议，像第一阶段协调者会等待所有参与者响应才会进行下一步操作，当然第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。

在第二阶段协调者的没法超时，因为按照我们上面分析只能不断重试！

3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

4 太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

3. 3PC

3PC 的出现是为了解决 2PC 的一些问题，相比于 2PC 它在参与者中也引入了超时机制，并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态。

与两阶段提交不同的是，三阶段提交有两个改动点：

• 1、引入超时机制。同时在协调者和参与者中都引入超时机制。
• 2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

这里的引入超时机制是指第二阶段的，对应2pc来说，第一阶段也有超时的，第二节点没有超时

3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段，对应的英文就是：CanCommit、PreCommit 和 DoCommit。

3.1 CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

3.2 PreCommit阶段

协调者根据CanCommit阶段参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

场景一 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行，即PreCommit。

• 1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。

• 2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

• 3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

场景二 假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断:

• 1.发送中断请求 协调者向所有参与者发送abort请求。

• 2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

总结：

• 假设CanCommit阶段，某个参与者返回的是yes，如果返回消息超时，协调者未收到yes，协调者也会认定CanCommit阶段失败。总结：CanCommit阶段只要有任意一个参与者超时没给回应，不管该回应是yes还是no，协调者默认判定为失败。

• 假设PreCommit阶段，协调者发送abort给参与者，发送超时，没有收到abort，参与者默认执行abort；同样，假设网络有问题，即使协调者发送PreCommit，参与者收不到，也会默认abort。总结：PreCommit阶段只要超时，各个参与者默认执行abort，同时，协调者也会判断失败

3.3 doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

执行提交:

• 1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
• 2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
• 3.响应反馈 事务提交完之后，向协调者发送Ack响应。
• 4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。

中断事务 协调者没有接收到参与者发送的成功ACK响应（可能是接受者发送的不是成功ACK响应，也可能响应超时），那么就会执行中断事务：

• 1.发送中断请求 协调者向所有参与者发送abort请求
• 2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
• 3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
• 4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）

利用第二阶段的超时，默认执行事务的提交，而不是回滚。

3.4 2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章会介绍这个公认为难于理解但是行之有效的Paxos算法。

4. TCC补偿事务

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

• Try，对业务系统做检测及资源预留。和二阶段中提交协议，提交请求阶段类似，系统会将需要确认的资源预留、锁定，确保确认操作一定能执行成功
• Confirm，确认执行业务操作。和二阶段提交协议中，提交执行阶段的操作类似，指系统将最终执行操作
• Cancel，取消执行业务操作。比较像二阶段提交协议中的回滚操作，指系统将撤消之前预留的资源，也就是撤消已执行的预留操作对系统产生的影响

4.1 2pc与tcc区别

TCC和2PC两阶段提交类似，2PC通常是跨库的DB层面，TCC本质上是一个应用层面的2PC。

相对于 2PC、3PC ，TCC 适用的范围更大，但是开发量也更大，毕竟都在业务上实现，而且有时候你会发现这三个方法还真不好写。不过也因为是在业务上实现的，所以TCC可以跨数据库、跨不同的业务系统来实现事务。

5. 本地消息表（异步确保）

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。

• 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。

• 之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除(或者通过状态实现，例如开始是待发送状态，发送成功后修改为成功状态)，否则继续重新转发。

  如果发送失败也没事，会有后台任务定时去读取本地消息表，筛选出还未成功的消息再次调用对应的服务，服务更新成功了再变更消息的状态。因此需要注意幂等性，防止发送多次同一条消息。

• 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。

最终一致性会导致数据延迟，即某个时刻，数据是不一致的，但是最终数据是一致的。

缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

6. MQ 事务消息

有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中间件为例，其思路大致为：

第一阶段Prepared消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

优点： 实现了最终一致性，不需要依赖本地数据库事务。

缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。

参考

2PC和3PC
终于有人把“TCC分布式事务”实现原理讲明白了！
面试必问：分布式事务六种解决方案
分布式事务的四种解决方案