三阶段提交协议

三阶段提交协议在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。

三阶段的执行

CanCommit阶段

三阶段提交协议的的CanCommit阶段其实和两阶段提交协议的准备阶段很像。 协调者向参与者发送CanCommit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

PreCommit阶段

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

根据响应情况，有以下两种可能：

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

DoCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况:

• 执行提交：
  1. 发送提交请求。协调者接收到所有参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
  2. 事务提交。参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
  3. 响应反馈。事务提交完之后，向协调者发送ACK响应。
  4. 完成事务。协调者接收到所有参与者的ACK响应之后，完成事务。
• 中断事务： 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

三阶段提交协议和两阶段提交协议的不同

对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制（在两阶段提交协议中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败）。

在两阶段提交协议的准备阶段和提交阶段之间，插入预提交阶段，使三阶段提交协议拥有CanCommit、PreCommit、DoCommit三个阶段。 PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。

三阶段提交协议的缺点

如果进入PreCommit后，Coordinator发出的是abort请求，假设只有一个Cohort收到并进行了abort操作，而其他对于系统状态未知的Cohort会根据三阶段提交协议选择继续Commit，此时系统状态发生不一致性。