事务处理三阶段提交
在日常使用电商App下单时，你可能没意识到背后有一场“多方协商”正在紧张进行：扣减库存、生成订单、支付扣款，这些操作必须全部成功，否则就得一起回滚。这就是典型的分布式事务问题。而三阶段提交（3PC），正是为解决这类问题设计的一种协调机制。
相比大家更熟悉的两阶段提交（2PC），三阶段提交多了一个“准备确认”阶段，目的就是避免参与者长时间锁住资源，同时提升系统在异常情况下的可用性。
三阶段怎么走？
第一阶段叫“CanCommit”，协调者先问每个参与者：“你准备好提交事务了吗？”参与者根据自身状态回复“可以”或“不行”。这一步不锁定资源，只是试探。
第二阶段是“PreCommit”，当所有参与者都同意后，协调者发出预提交指令。参与者开始执行事务操作，写日志、加锁资源，但暂不提交。此时如果有人失败或超时，整个事务就会中止。
第三阶段是“DoCommit”，协调者正式通知提交。参与者收到后完成事务提交，并释放资源。如果这一阶段之前协调者挂了，参与者会在等待超时后自动提交——这是3PC和2PC的关键区别，避免了2PC中“单点阻塞”导致的死锁。
举个生活例子
就像朋友约饭，三阶段就像是：先群发消息“今晚有空吃饭吗？”（CanCommit）；大家都说OK，就订位置、点菜（PreCommit）；最后看到人都到齐了，才确认上菜（DoCommit）。万一组织者突然失联，大家等一会儿发现没动静，按事先约定直接开吃，不至于饿着干等。
代码示意一下流程
// 协调者发送 CanCommit 请求
<message type="CanCommit" to="participant1,participant2"/>
// 参与者返回准备状态
<response from="participant1" status="ready"/>
// 所有人都 ready 后，发送 PreCommit
<message type="PreCommit" to="all"/>
// 参与者执行本地事务，进入待提交状态
<log type="prepare" transaction_id="T1"/>
// 最终提交
<message type="DoCommit" to="all"/>当然，3PC也不是万能的。它依赖网络稳定和准确的超时判断，如果网络反复分区，仍可能出现数据不一致。但它确实在可用性和一致性之间，走出了一条更灵活的路。
对于现代微服务架构来说，完全靠3PC保证事务并不现实，但它启发了很多最终一致性方案的设计，比如补偿事务、消息队列事务消息等。理解3PC，就像理解交通规则一样，虽然不一定亲自开车上路，但知道怎么协作，才能让系统跑得更稳。