DDBS 3PC

为了弥补二阶段提交的缺点，研究者们在他的基础上，提出了三阶段提交。

3PC（三阶段提交）

3PC，全称 “three phase commit”，是 2PC 的改进版，其将 2PC 的 “提交事务请求” 过程一分为二，总共形成了 3 个部分：

• CanCommit
• PreCommit
• do Commit

阶段一：CanCommit

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

阶段二：PreCommit

协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。

执行事务预提交分为 3 个步骤：

1. 发送预提交请求：协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态。
2. 事务预提交：参与者受到 preCommit 请求后，会执行事务操作，对应 2PC 中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中。
3. 各参与者向协调者反馈事务执行的结果：如果参与者成功执行了事务，就反馈 Ack 响应，同时等待指令：提交（commit） 或终止（abor）。

中断事务也分为2个步骤：

1. 发送中断请求：协调者向所有参与者节点发出 abort 请求 。
2. 中断事务：参与者如果收到 abort 请求或者超时了，都会中断事务。

阶段三：do Commit

该阶段做真正的提交，同样也会出现两种情况：

执行提交

1. 发送提交请求：进入这一阶段，如果协调者正常工作，并且接收到了所有协调者的 Ack 响应，那么协调者将从 “预提交” 状态变为 “提交” 状态，并向所有的参与者发送 doCommit 请求 。
2. 事务提交：参与者收到 doCommit 请求后，会正式执行事务提交操作，并在完成之后释放在整个事务执行期间占用的事务资源。
3. 反馈事务提交结果：参与者完成事务提交后，向协调者发送 Ack 消息。
4. 完成事务：协调者接收到所有参与者反馈的 Ack 消息后，完成事务。

中断事务
假设有任何参与者反馈了 no 响应，或者超时了，就中断事务。

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

一旦进入阶段三，可能会出现 2 种故障：

• 协调者出现问题
• 协调者和参与者之间的网络故障

一段出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交。

• 优点：相比较 2PC，最大的优点是减少了参与者的阻塞范围（第一个阶段是不阻塞的），并且能够在单点故障后继续达成一致（2PC 在提交阶段会出现此问题，而 3PC 会根据协调者的状态进行回滚或者提交）。
• 缺点：如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题。