3PC是在2PC的基础上进行改进的，为了解决协2PC的同步阻塞，协调者单点，等容错机制缺失问题而提出的。
一、概念
将原本2PC的第二个阶段，即提交阶段拆分为两个部分，形成了由CanCommit、PerCommit和DoCommit三个阶段形成的事务处理协议。其协议涉及如下图所示（图上展示正常成功流程）：
阶段一：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，此时系统状态发生不一致性。