深入理解分布式事务中的三阶段提交（3PC），什么是3PC，3PC原理是怎样？3PC的优化?
在上一篇文章中，我们详细介绍了分布式事务中的两阶段提交，以及知道了两阶段提交存在一定的问题
深入理解分布式事务中的两阶段提交（2PC），什么是2PC，2PC原理是怎样？2PC有没有什么问题？解决方案？无法解决的情况？
-
同步阻塞问题：执行过程中，所有节点都是事务阻塞型的，当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态，也就是说，从投票阶段到提交阶段完成这段时间，资源是被锁住的
-
单点故障：协调者的故障会导致整个事务无法继续，参与者会一直阻塞，等待协调者回应，否则无法完成这次协议，整个系统就会进入阻塞态
三阶段提交协议是二阶段提交协议的改进版本，把两阶段提交协议的准备阶段一分为二，这样就有了
CanCommit、PreCommit、DoCommit 三个阶段
三阶段提交（3PC）
三阶段提交在两阶段提交的基础上增加了一个准备阶段，分为三个阶段：
- CanCommit阶段：协调者询问参与者是否可以提交事务，参与者返回 Yes 或 No。
- PreCommit阶段：协调者根据参与者返回的结果分为两种情况：
- 如果参与者有返回 No 或者等待超时后，协调者就向所有参与者发送 abort 请求，所有参与者收到 abort 请求或者超时未收到请求，执行事务的中断
- 如果所有参与者都返回 Yes，协调者发送 PreCommit 预提交请求，参与者执行事务并记录日志，如果都执行成功，则会返回 ACK 相应给协调者
- DoCommit阶段：协调者根据参与者返回的结果也分为两种情况：
- 任一参与者未发送 ACK 报文，或者发送的不是 ACK 报文，或者相应超时，那么协调者就会向所有参与者发送 abort 中断请求，所有参与者接收到之后执行事务回滚操作，并释放所有的事务资源，完成事务回滚后再发送 ACK 消息，协调者接收到后执行事务中断
- 协调者接收到所有参与者发送的 ACK 后，会发送 DoCommit 提交请求，参与者正式提交事务，并释放所有事物资源，提交完成后再向协调者发送 ACK 报文
三阶段提交协议的优化
同步阻塞问题优化
三阶段提交协议在第一个询问阶段时是并不锁定资源的，
在两阶段提交协议中，想象一下，如果有 10 个参与者和 1 个协调者，协调者在准备阶段发送 Prepare 消息，有 9 个 参与者正常返回同意，有一个返回中止或者超时不回，然后协调者就向所有参与者发送回滚请求，这不就浪费了很多的资源么？毕竟这期间 9 个参与者是锁定了资源的
同时，三阶段提交协议为参与者也增加了超时机制，两阶段提交中只有协调者有超时机制，一旦发生协调者宕机，整个系统就处于阻塞态了。
在进入第三阶段，如果参与者没有收到协调者发来的请求，会默认提交事务，而不会一直持有事务资源并处于阻塞状态
但是这种机制会出现数据一致性问题，如果协调者发送的是 abort 请求，那没收到的参与者就与收到的参与者的数据不一致了
总结
从协调者收到一次事务请求、发起提议到事务完成，两阶段提交协议是 2 次 RTT，即准备阶段和提交阶段，而三阶段提交协议是 3 次 RTT（CanCommit+PreCommit+Docommit），但是允许参与者自主决策，防止协调者宕机后整个系统处于阻塞态，增加了系统的可用性，对一些现实业务场景是非常值得的
**不论两阶段提交还是三阶段提交，都无法彻底解决分布式的一致性问题。**在极端情况下，会出现事务预提交成功，但事务确认提交失败的情况，事务管理器会记录事务日志，根据事务日志进行恢复，人工干预环节是无法避免的。