Three-Phase Commit[3PC]，三阶段提交，是二阶段提交[2PC]的升级版，最大的区别在于两处：

  • 对于协调者[Coordinator]和参与者[Cohort]都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败）。

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

那么有了这两个区别，3PC比2PC的提高到底在哪里？其实就是在二阶段提交的文章中，所叙述的问题3，即Coordinator和Cohort全出错了怎么办？先介绍整个3PC流程，再回答这个问题。

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。[如何判断是否可以提交不同的算法有不同的机制，但主要作用是确定Cohort具备基本的完成Commit条件，并不会执行事务操作]

  1. 事务询问。Coordinator向Cohort发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

  2. 响应反馈。Cohort接到CanCommit请求之后，正常情况下，如果其自身可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段

Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。假如Coordinator从所有的Cohort获得的反馈都是Yes响应，那么就会进行事务的预执行：

  1. 发送预提交请求。Coordinator向Cohort发送PreCommit请求，并进入Prepared阶段。

  2. 事务预提交。Cohort接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

  3. 响应反馈。如果Cohort成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个Cohort向Coordinator发送了No响应，或者等待超时之后，Coordinator都没有接到Cohort的响应，那么就中断事务：

  1. 发送中断请求。Coordinator向所有Cohort发送abort请求。

  2. 中断事务。Cohort收到来自Coordinator的abort请求之后（或超时之后，仍未收到Cohort的请求），执行事务的中断。

DoCommit阶段

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

执行提交

  1. 发送提交请求。Coordinator接收到Cohort发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有Cohort发送doCommit请求。
  2. 事务提交。Cohort接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
  3. 响应反馈。事务提交完之后，向Coordinator发送ACK响应。
  4. 完成事务。Coordinator接收到所有Cohort的ACK响应之后，完成事务。

中断事务

Coordinator没有接收到Cohort发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

  1. 发送中断请求。Coordinator向所有Cohort发送abort请求
  2. 事务回滚。Cohort接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
  3. 反馈结果。Cohort完成事务回滚之后，向Coordinator发送ACK消息
  4. 中断事务。Coordinator接收到参与者反馈的ACK消息之后，执行事务的中断。

在doCommit阶段，如果Cohort无法及时接收到来自Coordinator的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么Coordinator产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了。所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。）

好了，回到文章开头的问题，如果在2PC中Coordinator和Cohort都出错怎么办？这个问题又可以再分，为了给自己说明白分的比较细，其实很多情况是可以不用考虑的，其中1-5的一致性不会被破坏或者可以解决，而6就是3PC想解决的问题。

  1. Coordinator在发出Prepare消息之前出错，全部Cohort出错（那个系统根本就是崩溃，跟不用说后面的操作了）
  2. Coordinator在发出Prepare消息之前出错，部分Cohort出错（这个也不会出现后面的操作，不过可能不同的实现机制，会有选新Coordinator的情况？）
  3. Coordinator在发出Prepare消息之后出错，全部Cohort出错（那这个Prepare消息就算石沉大海了，也不会有后续操作）
  4. Coordinator在发出Prepare消息之后出错，部分Cohort出错（有部分Cohort收到Prepare的消息，发现无法跟Prepare正常交互后，要不处于等待状态，要不会选一个新的Coordinator，然后变成了2PC可以解决的问题1。此时没有任何节点进行实质的提交操作，可以根据undo回滚到原始状态，保证一致性）
  5. Coordinator在发出Commit消息之后出错，全部Cohort出错（那么没有任何Cohort会进行提交工作，因为没有人收到commit消息）
  6. Coordinator在发出Commit消息之后出错，部分Cohort出错（这个问题来了，一个极端的例子比如，只有一Cohort收到commit指令，进行实际操作，而他执行之后又出错了。那么即便没有出错的Cohort选出了一个新的Coordinator，他也无法获知此项操作的最终结果是commit还是abort）

如何解决问题6？就是超时机制，在6中，剩下的所有Cohort就是无所适从的状态。3PC的选择是让他们超时后默认进行commit操作。因为为Cohort也添加了超时机制，所以必须把提交状态再拆分，这就是3PC中的PreCommit和DoCommit。

最本质来讲，3PC避免了状态停滞，在2PC有可能因为各种原因，产生状态停滞。但是3PC会让状态继续下去，虽然有可能继续下去是错的。

3PC的问题是明显的（并没有完全解决2PC的问题3）：

即如果进入PreCommit后，Coordinator发出的是abort请求，如果只有一个Cohort收到并进行了abort操作，而其他对于系统状态未知的Cohort会根据3PC选择继续Commit，那么系统的不一致性就存在了。所以无论是2PC还是3PC都存在问题，后面会继续了解那个传说中唯一的一致性算法Paxos。