在分布式系统（Distributed System）的数据一致性保障中，事务提交协议是保证多个节点数据统一的核心方案，其中最经典、最常被问到的就是2PC（Two-Phase Commit，两阶段提交）和3PC（Three-Phase Commit，三阶段提交）。很多人容易混淆这两个协议，也不清楚它们各自的优缺点和适用场景，今天就用最简单直白的话，把两者的原理、流程和差异讲清楚。
首先我们要明确，2PC和3PC都是为了解决**分布式事务（Distributed Transaction）**的一致性问题，简单说就是多个服务或数据库节点，要么一起成功提交事务，要么一起失败回滚，不允许出现一部分成功、一部分失败的情况，否则就会产生数据不一致。
先来说2PC（Two-Phase Commit，两阶段提交），它的执行流程严格分为两个阶段，整个过程由一个叫做协调者（Coordinator）的核心节点统一管控，其他参与事务的节点叫做参与者（Participant）。第一个阶段是投票阶段（Voting Phase），协调者会向所有参与者发送事务准备请求，询问大家是否可以执行事务提交，参与者收到请求后，会执行事务操作但不真正提交，同时锁定资源，如果自身没问题就返回同意，有问题就返回拒绝。第二个阶段是执行阶段（Commit Phase），协调者根据所有参与者的投票结果做决定，如果全部同意，就向所有参与者发送提交指令，参与者完成最终提交并释放资源；只要有一个参与者拒绝，协调者就发送回滚指令，所有参与者都撤销事务操作。2PC的逻辑非常简单，实现成本低，也是目前很多分布式事务框架的基础，但它有明显的缺陷，比如协调者单点故障、参与者阻塞等待、同步执行效率低，而且一旦协调者在第二阶段宕机，参与者会一直锁定资源无法释放。
接下来是3PC（Three-Phase Commit，三阶段提交），它是在2PC的基础上做了优化改进，为了解决2PC的阻塞和单点问题，把流程拆成了三个阶段，同样由协调者（Coordinator）和参与者（Participant）完成。第一个阶段是CanCommit阶段，协调者只是询问参与者是否有能力执行事务，参与者不需要执行操作、也不锁定资源，只返回是否就绪，这一步和2PC的投票阶段不同，不会产生资源阻塞。第二个阶段是PreCommit阶段，如果所有参与者都返回就绪，协调者就发送预提交请求，参与者这时才执行事务操作但不提交，同时锁定资源，返回执行成功的响应。第三个阶段是DoCommit阶段，协调者根据PreCommit的结果，发送最终的提交或回滚指令，参与者完成提交或回滚后释放资源。3PC最关键的优化有两点，一是增加了预提交阶段，降低了阻塞风险，二是给参与者设置了超时机制（Timeout Mechanism），如果参与者长时间收不到协调者的指令，会自动执行提交操作，避免一直锁定资源。
对比两者的核心差异，我们可以清晰梳理：2PC只有两个阶段，流程简单但存在严重的阻塞问题，协调者宕机就会导致参与者资源无法释放，容错性很差；3PC多了一个预提交阶段，并且加入超时机制，解决了2PC的阻塞问题，容错性更高，但它的流程更复杂，通信次数更多，整体执行效率比2PC更低，而且3PC也不是完美的，在极端的网络分区场景下，依然有可能出现数据不一致的情况。在实际的分布式系统应用中，2PC因为实现简单，被用于MySQL集群、XA事务等场景，而3PC更多是理论层面的优化，实际工程中很少直接使用，更多是作为分布式事务协议的参考思路。
最后做一个简洁总结：2PC两阶段，简单易实现，协调者单点易阻塞；3PC三阶段，加预提和超时，解阻塞但效率低，极端场景仍不一致。
