面试题：两阶段提交与三阶段提交的区别？

主要区别有以下几点：

• 增加了一个询问阶段，问了下，你能不不能行？
• 加入了超时机制

2PC（二阶段提交协议）

2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者预提交成功，则进行第二阶段的资源提交，否则事务协调者回滚资源

1、第一阶段：预提交阶段

由事务协调者询问通知各个事务参与者，是否准备好了执行事务，具体流程图如下：

• ① 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复

• ② 各参与者执行本地事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）

• ③ 如参与者执行成功，给协调者反馈同意，否则反馈中止，表示事务不可以执行

undo一般用于事务的记取消与回滚，录的是数据修改前的值；

redo一般用于恢复已确认但未写入数据库的数据，记录的是数据修改后的值。

2、第二阶段：提交阶段

协调者收到各个参与者的准备消息后，根据反馈情况通知各个参与者commit提交或者rollback回滚

接下来分两种情况分别讨论提交阶段的过程。

（1）事务提交：

当第一阶段所有参与者都反馈同意时，协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，具体流程如下：

① 协调者节点向所有参与者节点发出正式提交的 commit 请求。

② 收到协调者的 commit 请求后，参与者正式执行事务提交操作，并释放在整个事务期间内占用的资源。

③ 参与者完成事务提交后，向协调者节点发送ACK消息。

④ 协调者节点收到所有参与者节点反馈的ACK消息后，完成事务。

所以，正常提交时，事务的完整流程图如下：

（2）事务回滚：

如果任意一个参与者节点在第一阶段返回的消息为中止，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时，那么这个事务将会被回滚，具体流程如下：

① 协调者向所有参与者发出 rollback 回滚操作的请求

② 参与者利用阶段一写入的undo信息执行回滚，并释放在整个事务期间内占用的资源

③ 参与者在完成事务回滚之后，向协调者发送回滚完成的ACK消息

④ 协调者收到所有参与者反馈的ACK消息后，取消事务

所以，事务回滚时，完整流程图如下：

2PC缺点：

二阶段提交确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的：

（1）性能问题：执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景

（2）可靠性问题：2PC非常依赖协调者（带头大哥），当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

（3）数据一致性问题：在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

（4）二阶段无法解决的问题：协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

3PC（三阶段提交协议）

3PC，三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改动点：

（1）在协调者和参与者中都引入超时机制

（2）在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

所以3PC会分为3个阶段，

CanCommit 准备阶段、（你能不能行？）

PreCommit 预提交阶段、

DoCommit 提交阶段，处理流程如下：

1、阶段一：CanCommit 准备阶段

协调者向参与者发送 canCommit 请求，参与者如果可以提交就返回Yes响应，否则返回No响应，具体流程如下：

（1）事务询问：协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。

（2）响应反馈：参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

2、阶段二：PreCommit 阶段

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

（1）执行事务：

假如所有参与者均反馈 yes，协调者预执行事务，具体如下：

① 发送预提交请求：协调者向参与者发送 PreCommit 请求，并进入准备阶段

② 事务预提交 ：参与者接收到 PreCommit 请求后，会执行本地事务操作，并将 undo 和 redo 信息记录到事务日志中（但不提交事务）

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

（2）中断事务：

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

① 发送中断请求 ：协调者向所有参与者发送 abort 请求。

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

3、阶段三：doCommit阶段

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

（1）提交事务：

① 发送提交请求：协调接收到所有参与者发送的ACK响应，那么他将从预提交状态进入到提交状态，并向所有参与者发送 doCommit 请求

② 本地事务提交：参与者接收到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源

③ 响应反馈：事务提交完之后，向协调者发送ack响应。

④ 完成事务：协调者接收到所有参与者的ack响应之后，完成事务。

（2）中断事务：

任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务

① 发送中断请求：如果协调者处于工作状态，向所有参与者发出 abort 请求

② 事务回滚：参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

③ 反馈结果：参与者完成事务回滚之后，向协调者反馈ACK消息

④ 中断事务：协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

进入doCommit阶段后，无论协调者出现问题，或者协调者与参与者之间的网络出现问题，都会导致参与者无法接收到协调者发出的 doCommit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。这其实基于概率来决定的，当进入第三阶段时，说明第一阶段收到所有参与者的CanCommit响应都是Yes，意味着大家都同意修改了，并且第二阶段所有的参与者对协调者的PreCommit请求也都是yes的。所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。

3PC的优缺点

与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者或参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。

数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

---

2PC和3PC都无法保证数据绝对的一致性，一般为了预防这种问题，可以添加一个报警，比如监控到事务异常的时候，人为干预，通过脚本自动补偿差异的信息。