三阶段提交，是二阶段提交(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条件，并不会执行事务操作)
事务询问。Coordinator向Cohort发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
响应反馈。Cohort接到CanCommit请求之后，正常情况下，如果其自身可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
PreCommit阶段
Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。假如Coordinator从所有的Cohort获得的反馈都是Yes响应，那么就会进行事务的预执行：
发送预提交请求。Coordinator向Cohort发送PreCommit请求，并进入Prepared阶段。
事务预提交。Cohort接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
响应反馈。如果Cohort成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个Cohort向Coordinator发送了No响应，或者等待超时之后，Coordinator都没有接到Cohort的响应，那么就中断事务：
发送中断请求。Coordinator向所有Cohort发送abort请求。
中断事务。Cohort收到来自Coordinator的abort请求之后（或超时之后，仍未收到Cohort的请求），执行事务的中断。
DoCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
执行提交
发送提交请求。Coordinator接收到Cohort发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有Cohort发送doCommit请求。
事务提交。Cohort接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
响应反馈。事务提交完之后，向Coordinator发送ACK响应。
完成事务。Coordinator接收到所有Cohort的ACK响应之后，完成事务。
中断事务
Coordinator没有接收到Cohort发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
发送中断请求。Coordinator向所有Cohort发送abort请求
事务回滚。Cohort接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
反馈结果。Cohort完成事务回滚之后，向Coordinator发送ACK消息
中断事务。Coordinator接收到参与者反馈的ACK消息之后，执行事务的中断。
在doCommit阶段，如果Cohort无法及时接收到来自Coordinator的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么Coordinator产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了。所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。）
好了，回到文章开头的问题，如果在2PC中Coordinator和Cohort都出错怎么办？这个问题又可以再分，为了给自己说明白分的比较细，其实很多情况是可以不用考虑的，其中1-5的一致性不会被破坏或者可以解决，而6就是3PC想解决的问题。
Coordinator在发出Prepare消息之前出错，全部Cohort出错（那个系统根本就是崩溃，跟不用说后面的操作了）
Coordinator在发出Prepare消息之前出错，部分Cohort出错（这个也不会出现后面的操作，不过可能不同的实现机制，会有选新Coordinator的情况？）
Coordinator在发出Prepare消息之后出错，全部Cohort出错（那这个Prepare消息就算石沉大海了，也不会有后续操作）
Coordinator在发出Prepare消息之后出错，部分Cohort出错（有部分Cohort收到Prepare的消息，发现无法跟Prepare正常交互后，要不处于等待状态，要不会选一个新的Coordinator，然后变成了2PC可以解决的问题1。此时没有任何节点进行实质的提交操作，可以根据undo回滚到原始状态，保证一致性）
Coordinator在发出Commit消息之后出错，全部Cohort出错（那么没有任何Cohort会进行提交工作，因为没有人收到commit消息）
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都存在问题。
