两阶段提交（2PC）通过准备和提交/回滚两个阶段确保分布式事务的原子性与一致性：第一阶段各参与者预写日志、加锁并投票；第二阶段协调者依据投票结果统一指令提交或中止，要求日志持久化优先于指令发送。
SQL数据库的事务提交，特别是分布式环境下的跨节点事务，通常依赖两阶段提交（Two-Phase Commit, 2PC）来保证原子性和一致性。它不是简单执行一条 COMMIT 语句就结束，而是一个协调多个参与者协同决策的过程。
第一阶段：准备（Prepare）
协调者（通常是发起事务的应用或事务管理器）向所有参与该事务的数据库节点（参与者）发送 prepare 请求。每个参与者需完成以下动作：
- 将事务的修改写入本地 Redo 日志（确保崩溃后可恢复），但暂不写入实际数据页
- 锁定相关资源（如行锁、表锁），防止其他事务干扰
- 评估自身是否能成功提交：检查日志空间、锁冲突、约束违反等
- 向协调者返回“同意”（YES）或“中止”（NO）投票结果
若任一参与者返回 NO，协调者立即进入中止流程；全部 YES 才进入第二阶段。
第二阶段：提交（Commit）或回滚（Abort）
协调者根据第一阶段的投票结果统一决策：
- 若全部参与者投 YES：协调者写入自己的“全局提交日志”，再向所有参与者发送 commit 指令；各参与者将修改刷盘、释放锁、清理事务上下文
- 若任一参与者投 NO 或超时未响应：协调者写入“全局中止日志”，向所有参与者广播 abort 指令；各参与者回滚本地修改、释放锁
该阶段要求协调者持久化决策结果后再通知，避免单点故障导致状态不一致。
关键保障与常见问题
2PC 的核心价值在于强一致性，但代价明显：
- 阻塞风险：prepare 后参与者需保持锁和资源占用，直到收到最终指令；协调者宕机可能导致参与者长期等待
- 单点依赖：协调者是关键瓶颈，需高可用设计（如主备切换、日志复制）
- 非幂等性：重复的 commit/abort 指令可能引发异常，参与者必须支持“重复指令幂等处理”
- 日志持久化顺序：协调者必须先落盘“决策日志”，再发指令；参与者须先落盘“prepare 日志”，再投票
实际应用中的简化与替代
纯 2PC 在高并发、跨异构系统场景下开销大，因此常被优化或替代：
- 多数数据库（如 PostgreSQL、MySQL InnoDB）在单机事务中用 WAL + 两段锁实现原子提交，不暴露完整 2PC 协议
- 分布式数据库（如 TiDB、CockroachDB）采用类 2PC 的变体（如 Percolator、Raft-based commit），结合时间戳或共识算法降低协调开销
- 微服务架构常用 Saga 模式替代 2PC，以业务补偿代替强一致，换取可用性与性能
理解 2PC 不是为了手动实现，而是为了诊断分布式事务卡顿、死锁、悬挂事务等问题提供底层视角。
