3PC是在2PC的基础上进行改进的，为了解决协2PC的同步阻塞，协调者单点，等容错机制缺失问题而提出的。

一、概念

将原本2PC的第二个阶段，即提交阶段拆分为两个部分，形成了由CanCommit、PerCommit和DoCommit三个阶段形成的事务处理协议。其协议涉及如下图所示（图上展示正常成功流程）：

3PC (1).png

阶段一：CanCommit

1）事务询问：事务协调者向各参与者发送包含事务内容的CanCommit请求，询问是否可以提交事务。并开始等待各参与者响应。

2）参与者反馈事务询问响应给协调者：各参与者收到协调者的CanCommit请求后，如果自身能够执行事务则返回yes，否则返回no。

阶段二：PerCommit
会有两种情况：执行事务预提交和中断事务

执行事务预提交：
1）发送预提交请求：协调者向各参与者发送预提交请求，并进入Prepared阶段。

2）事务预提交：参与者接收到perCommit请求后，会执行实务操作，并记录Undo log和Redo log。

3）各参与者向协调者反应事务执行的响应ack：如果参与者成功执行了事务操作，就会反馈给协调者ack，等待commit（提交）或者abort（中止）。

中断事务：
如果任何一个事务参与者向协调者返回No，或者等待超时后，协调者无法接收到所有参与者的反馈响应，那么就会事务中断。
1）发送中断请求：协调者向各参与者发送中断请求。

2）中断事务：无论参与者是否收到协调者的中止请求，在超时后仍然后会中断事务。

阶段三：DoCommit
存在两种情况：提交事务和中断事务

执行提交：
1）发送提交请求：协调者接收到所有参与者的ack响应，将会从预提交转换为提交状态，并向所有参与者发送doCommit请求。

2）事务提交：参与者接收到doCommit请求后，会正式执行事务操作，最终提交事务释放资源占用。

3）反馈事务提交结果：参与者完成事务提交后向协调者发送ack响应。

4）完成事务：协调者收到所有参与者反馈的ack后，完成事务。

中断事务：
如果任何一个事务参与者向协调者返回No，或者等待超时后，协调者无法接收到所有参与者的反馈响应，那么就会事务中断。

1）发送中断请求：协调者向所有参与者发送abort请求。

2）事务回滚：参与者接收到abort请求后，使用Undo log进行回滚操作，回滚后释放占用资源。

3）反馈事务回滚结果：所有参与者在完成回滚后，向协调者发送ack。

4）中断事务：协调者接收到所有参与者反馈的ack，中断事务。

注意：一旦所有参与者完成二阶段准备提交，当进入第三阶段后，协调者出现故障，或参与者与协调者出现网络问题，在超时后，参与者都会进行事务提交。

二、优缺点

优点：相比于二阶段提交，增加了perCommit的缓冲，三阶段提交降低了参与者的阻塞范围，能够在出现单点故障后继续达成一致。

缺点：如果进入PreCommit后，协调者发出的是abort请求，假设只有一个参与者收到并进行了abort操作，而其他对于系统状态未知的参与者会根据3PC选择继续Commit，此时系统状态发生不一致性。