「这是我参与11月更文挑战的第9天，活动详情查看：2021最后一次更文挑战」

2PC

介绍

两阶段提交（Two-Phase Commit，以下简称2PC）方案，通常也被称为一种协议，从字面意思理解就是事务分两个阶段进行提交，整个方案在执行分布式事务的过程中被分为两个重要阶段：

准备阶段（Prepare Phase）：事务发起方通过事务管理器发起一个分布式事务后，由事务协调器（事务管理器）通知各个事务参与方（资源管理器），给他们发送一条prepare指令，每个参与者要么返回失败，要么就进行执行本地事务（分支事务），写本地redo和undo日志，但是不进行事务的commit，到达一种临界状态，此时每个参与者持有当前本地事务涉及的锁资源不释放；

二阶段——提交阶段（Commit Phase）：事务协调器收集所有事务参与方在一阶段返回的信息，如果都成功则通知所有参与方进行事务提交（Commit），如果有返回失败或超时，则通知所有参与方进行事务回滚（Rollback）。参与方根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

优点

• 数据库层面（资源管理器）层面控制分布式事务，业务层面无感知或低侵入
• 强一致性

缺点

• 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

• 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

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

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

由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。

3PC

相比二阶段提交，三阶段提交有几下升级点：

• 三阶段提交协议引入了超时机制。

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

 简单讲：就是除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

三阶段详细介绍

阶段一（CanCommit 阶段）

类似于2PC的准备（第一）阶段。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

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

阶段二（PreCommit 阶段）
协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。

此阶段分两种情况：

事务预提交： 所有参与者均反馈YES时

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

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

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

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

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

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

阶段三（ DoCommit阶段）
此阶段也存在两种情况：
1、所有参与者均反馈Ack响应，
2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。

提交事务： （所有参与者均反馈Ack响应时，即执行真正的事务提交。）
1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。

中断事务： （任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

注意：进入阶段三后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时，参与者都会在等待超时之后，继续执行事务提交。

优点

相对于二阶段提交协议

1. 降低了参与者的阻塞范围
2. 出现单点故障后继续达成一致

缺点

参与者接收到 PreCommit 消息后，如果网络出现分区，此时协调者和部分参与者无法进行正常的网络通信，该部分参与者依然会进行事务的提交，必然出现数据的不一致性。

本文已参与「新人创作礼」活动，一起开启掘金创作之路。