针对两阶段提交的问题，三阶段提交引入了 预询盘 阶段及 超时策略 来减少整个集群的阻塞时间，来提升系统性能。

一、步骤

1.1 第一阶段：预询盘

该阶段协调者会去询问各个参与者是否能够正常执行事务，参与者根据自身情况回复一个预估值，相对于真正的执行事务，这个过程是轻量的，具体步骤如下：

协调者向各个参与者发送事务询问通知，询问是否可以执行事务操作，并等待回复；

各个参与者依据自身状况回复一个预估值，如果预估自己能够正常执行事务就返回确定信息，并进入预备状态，否则返回否定信息。

该步骤的意义在于，可以在发送prepare请求之前，更提前一步探知参与者的状态。因为：

接收 prepare 请求之后，参与者需要执行对应的方法，是比较重的操作

参与者如果回复了 yes，那么意味着其需要一直等待协调者的 commit/abort 消息

如果更早确定了参与者是否可正确执行事务，那么可以减少原来在 prepare 阶段的失败率，进一步也减少了参与者的阻塞时间

1.2 第二阶段：预提交

类似于2PC的预提交，只不过这一步的预提交需要根据预询盘的结果来做出相应决策。预询盘结果主要有三种：

所有的参与者都返回确定信息。

一个或多个参与者返回否定信息。

协调者等待超时。

针对第 1 种情况，协调者会向所有参与者发送事务执行请求，具体步骤如下：

协调者向所有的事务参与者发送事务执行通知；

参与者收到通知后执行事务但不提交；

参与者将事务执行情况返回给客户端。

在上述步骤中，如果参与者等待超时，则会中断事务。 针对第 2 和第 3 种情况，协调者认为事务无法正常执行，于是向各个参与者发出 abort 通知，请求退出预备状态，具体步骤如下：

协调者向所有事务参与者发送 abort 通知；

参与者收到通知后中断事务。

1.3 第三阶段：事务提交

如果第二阶段事务未中断，那么本阶段协调者将会依据事务执行返回的结果来决定提交或回滚事务，分为 3 种情况：

所有的参与者都能正常执行事务。

一个或多个参与者执行事务失败。

协调者等待超时。

针对第 1 种情况，协调者向各个参与者发起事务提交请求，具体步骤如下：

协调者向所有参与者发送事务 commit 通知；

所有参与者在收到通知之后执行 commit 操作，并释放占有的资源；

参与者向协调者反馈事务提交结果。

针对第 2 和第 3 种情况，协调者认为事务无法成功执行，于是向各个参与者发送事务回滚请求，具体步骤如下：

协调者向所有参与者发送事务 abort 通知；

所有参与者在收到通知之后执行 abort 操作，并释放占有的资源；

参与者向协调者反馈事务回滚结果。

在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 abort 请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续 commit，相对于两阶段提交虽然降低了同步阻塞，但仍然无法完全避免数据的不一致。

也就是说，有可能协调者其实是需要参与者 abort 事务的，但参与者实际上去 commit 事务，这种会导致数据的不一致。且这种不一致需要人工接入修复了。

二、优缺点

2.1 优点

消除阻塞：3PC引入超时策略，当参与者回复prepare消息处于等待协调者的commit消息状态时，在规定时间内没有收到消息，则会继续commit事务

2.2 缺点

其缺点也正是优点的另一面：无法保证原子性

在无限延迟的网络环境中，超时机制并不是可靠的故障检测方法，无法保证原子性，存在数据不一致的问题。因此尽管2PC有阻塞问题但还是会比3PC应用多一些。