一句话定义：两阶段提交（Two-Phase Commit，2PC）是一种分布式事务协议，让多个数据库或服务"要么一起成功，要么一起失败"，代价是慢，而且协调者一出事就可能全线卡住。
它怎么工作
打个比方：一份合同要五位合伙人签字才生效，于是推举一个人当"协调者"。第一步，协调者挨个问："你愿意签吗？"每个人先检查自己的条款没问题，回答"愿意"，然后把笔按在纸上不落笔——资源先锁住。第二步，只有五个人全说愿意，协调者才喊"全体签字"；只要有一个人说不行，就喊"全体作废"。
对应到技术里：第一阶段叫准备（投票）阶段，参与者要写日志、锁住数据、回复"可以提交"；第二阶段叫提交阶段，协调者根据投票结果下发 commit 或 abort。
为什么又慢
一是轮次多。一次事务至少两轮网络往返，而分布式事务的耗时取决于最慢的那个参与者，任何一个节点抖动都会拖累整体。
二是要落盘。参与者回复"可以提交"是一种承诺，必须写日志保证崩溃后还能兑现，这通常意味着磁盘同步写（fsync），比内存操作慢好几个数量级。
三是锁持得久。从"准备完成"到收到最终决定的这段时间，行锁一直不放，热点数据上其他事务只能排队。延迟高、吞吐掉，往往就在这里。
为什么容易卡死
关键在于 2PC 是阻塞式协议。参与者一旦投了"愿意"，它就进入了"不确定"状态：既不能自己回滚，也不能自己提交，只能等协调者的最终决定。
如果协调者这时宕机，或者网络分区把消息吞了，参与者就一直举着笔僵在原地，锁不放，后面所有请求全部堵死，可能要人工介入才能恢复。这不是实现得不好，而是协议本身的设计缺陷。相比之下，3PC（三阶段提交）把准备阶段再拆细、加入超时推断，能缓解但无法彻底消除这个问题；而把提交决定放进 Raft、Paxos 这类共识日志中，用多数派选主来替代单点协调者，是目前更常见的工程思路。具体数据库、中间件支持到什么程度，以各自的官方文档为准。
和相邻概念的区别
| 方案 | 一致性 | 是否阻塞 | 主要代价 |
|---|---|---|---|
| 单库本地事务 | 强一致 | 否 | 跨不了库 |
| 2PC | 强一致 | 是 | 延迟高、锁时间长 |
| 3PC | 强一致 | 缓解未消除 | 轮次更多 |
| Saga / TCC | 最终一致 | 否 | 要写补偿逻辑，隔离性弱 |
对从业者的意义
凡是"跨库、跨服务、跨分片还要强一致"的场景，2PC 都会被提起：分库分表下的转账、微服务里同时写订单库和库存库、AI 系统里在线特征与离线特征的同步写、训练元数据与数据文件的登记等。
实用建议是：能收敛到单库事务就别拆；必须跨多个存储时，优先考虑最终一致 + 幂等重试 + 补偿（Saga）、本地消息表 / Outbox 模式，把"不确定窗口"从数据库锁里挪到可重放的消息里。2PC 更适合低频、短小、参与方少的强一致操作——它是一把精确但沉重的锁，不适合拿来跑高并发主链路。