分布式理论（四）3PC协议

3PC：three phase commit 三阶段提交协议，是二阶段提交的改进

三阶段提交的两个改动点：

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

阶段一：Can Commit

1. 事务询问。协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 各个参与者向协调者反馈事务询问的响应。参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，并进入预备状态，否则反馈 No 响应。

阶段二：Pre Commit（分情况执行）

根据参与者的响应情况，来决定是否可以执行事务的PreCommit操作。有以下2种可能。

1. 执行事务预执行。协调者从所有的参与者获得的反馈都是Yes响应，执行事务的预执行。
   1. 发送预提交请求。协调者向参与者发送PreCommit请求，并进入Prepared阶段。
   2. 事务预提交 。参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
   3. 响应反馈。如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
2. 执行事务中断。有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应执行事务的中断。
   1. 发送中断请求。协调者向所有参与者发送abort请求。
   2. 中断事务。参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

 

阶段三：Do Commit，（分情况执行）进行真正的事务提交

1. 执行提交。协调者从所有的参与者获得的反馈都是Yes响应，执行事务的提交。
   1. 发送提交请求。协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
   2. 事务提交。参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
   3. 响应反馈。事务提交完之后，向协调者发送Ack响应。
   4. 完成事务。协调者接收到所有参与者的ack响应之后，完成事务。
2. 中断事务。协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
   1. 发送中断请求。协调者向所有参与者发送abort请求
   2. 事务回滚。参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
   3. 反馈结果。参与者完成事务回滚之后，向协调者发送ACK消息
   4. 中断事务。协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

 

【注意】在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。

 

整个过程图

 

优缺点：

• 优点：解决了单点故障，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。减少了阻塞范围（第一个阶段是不阻塞的）。
• 缺点：数据不一致，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

参考：

2PC&&3PC：https://www.jianshu.com/p/dd6a340e50b2

分布式理论（四）—— 一致性协议之 3PC：https://www.cnblogs.com/stateis0/p/9062128.html