三阶段提交是在二阶段提交上的改进版本，3PC 最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段再次一分为二，这样三阶段提交。

处理流程如下 ：

阶段一

• 协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
• 参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段二

协调者根据参与者响应情况，有以下两种可能。

情况1： 所有参与者均反馈 yes，协调者预执行事务

• 协调者向所有参与者发出 preCommit 请求，进入准备阶段。
• 参与者收到 preCommit 请求后，执行事务操作，将 undo 和 redo 信息记入事务日志中（但不
  提交事务）。
• 各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。

情况2： 只要有一个参与者反馈 no，或者等待超时后协调者尚无法收到所有提供者的反馈，即中断事务

• 协调者向所有参与者发出 abort 请求。
• 无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事
  务。

阶段三

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

情况 1： 所有参与者均反馈 ack 响应，执行真正的事务提交

• 如果协调者处于工作状态，则向所有参与者发出 do Commit 请求。
• 参与者收到 do Commit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
• 各参与者向协调者反馈 ack 完成的消息。
• 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况2： 只要有一个参与者反馈 no，或者等待超时后协调组尚无法收到所有提供者的反馈，即回滚事务。

• 如果协调者处于工作状态，向所有参与者发出 rollback 请求。
• 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
• 各参与者向协调组反馈 ack 完成的消息。
• 协调组收到所有参与者反馈的 ack 消息后，即完成事务回滚。

优点： 相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务。

缺点： 数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造
成数据不一致。