三阶段提交协议（3PC）

三阶段提交协议出现的背景：一致性协议中设计出了二阶段提交协议，但是2PC设计存在缺陷，于是有了三阶段提交协议。

三阶段提交协议

3PC，全称为“Three phase commit”，是2PC的改进版，将2PC的“事务提交过程”一分为二，并形成了canCommit、preCommit和doCommit三个阶段组成的事务处理协议。

三阶段提交升级点（基于二阶段）：

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

• 在第一阶段和第二阶段中，引入了一个准备阶段。保证最后提交之前，各个节点之间数据一致性。

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

  preCommit、doCommit三个阶段。

三阶段详解

• 第一阶段（canCommit）

  类似于2PC的准备阶段（preCommit）。

  协调者向参与者发送Commit请求，参与者如果可以提交就发生yes响应，否则返回No响应。

  • 事务询问

    协调者向参与者发送canCommit请求。询问是否可以进行事务提交操作，然后开始等待参与者的响应。

  • 响应反馈

    参与者接收到canCommit请求之后，正常情况下，如果自身可以执行事务，则返回Yes响应，并进入预备状态。否则反馈No

• 第二阶段（preCommit）

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

  • Yes

    （1）发送预提交请求

    协调者向参与者发送preCommit请求，并进入prepared阶段。

    （2）事务预提交

    参与者接收到preCommit请求之后，会执行事务操作，并将undo信息和redo信息记录到事务日志中。

    （3）响应反馈

    如果参与者成功执行了事务操作，则返回ACK响应，并且开始等待最终指令。

  • No

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

    （1）发送中断请求

    协调者向参与者发送abort请求

    （2）中断事务

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

• 第三阶段（doCommit）

  该阶段进行真正的事务提交，也可以分为执行事务和中断事务两种情况

  • 执行成功

    （1）发送提交请求

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

    （2）事务提交

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

    （3）响应反馈

    事务提交完之后，向协调者发送ACK响应。

    （4）完成事务

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

  • 中断事务

    （1）发送中断请求

    协调者向所有参与者发送abort请求

    （2）事务回滚

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

    （3）反馈结果

    参与者完成事务回滚之后，想协调者发送ACK消息

    （4）中断事务

    协调者接收到所有参与者的ACk消息之后，进行事务的中断

    一旦进入阶段三，可能会有两种故障

    （1）协调者出现问题

    （2）协调者和参与者之间的网络故障

如果出现了任何一种情况，都可能出现参与者无法收到doCommit请求或者abort请求，参与者都会在等待超时之后进行事务提交。

3PC和2PC对比

对于协调者和参与者都设置了超时协议（在2PC中，只有协调者有超时机制，如果在一定时间内没有收到参与者的消息默认失败）。主要避免了参与者长时间无法与协调者节点通讯的情况下（或者协调者挂掉），无法释放资源的问题。因为参与者自身有超时机制，会在超时后，自动进行本地commit而释放资源。这种机制从侧面降低了整个事务的阻塞时间和范围。

通过canCommit、preCommit、doCommit三个阶段设计，相对于2PC而言，多设置了一个缓冲阶段，保证了最后提交阶段之前各个参与节点的状态一致。

preCommit是一个缓冲，保证了最后提交节点之前，各个节点的状态是一致的。

3PC没有完全解决数据一致性的问题。