题目：2PC 协议"阻塞"问题详解
难度：high
评分：⭐⭐⭐☆☆
两阶段提交它的主涉是一个它的核心问题，它主涉本质上就是要确认所有人都是可以通信的，可以正常完成当前事务的。这个通信的过程需要等待，发起者与处理者都需要进行对应的处理，所以为了保证事务的正常进行，大家需要把资源都统筹起来，这个过程会产生阻塞。正常的阻塞是没有什么异常的，如果中间出现了问题，比如协调者出现崩溃，导致所有的信息无法正常传递，然后网络相互间无法通讯，然后造成长时间的等待，导致资源的浪费，最终导致服务拖垮。可能会有相关的问题产生。修复方式的话，首先是要发现这个类似的问题，比如事务时间过长，监控指标中要有记载。然后如果出现了一些长事务，事务的执行时间过长，然后要做出告警。另外是对于锁的监控，也要有相关的监控。锁的量上出现了数量上的激增，或者是服务资源处上异常，对应的要能快速找到对应的方向问题。然后首先可以是释放资源，将对应的事务处理掉。然后其实本质上应该在事务那设置过期时间，让它快速的结束，而不是资源长时间等待，导致整个业务的拖垮。
评分：⭐⭐⭐☆☆
优点：
不足（high 难度要求精确描述技术细节）：
补充：
核心考点定位：考察对 2PC 协议"阻塞"缺陷的精确理解——不止"会阻塞"，还要讲清楚为什么是不确定状态、靠 redo log 怎么恢复、工程上怎么缓解。
知识点拆解：
场景 1：协调者崩溃在 Prepare 之后、Commit 之前（最关键）
├─ 参与者 1 和 2 都写完了 redo log，返回 Prepare OK
├─ 协调者写完日志、准备发 Commit 时崩溃
└─ 结果：参与者持有锁，状态不明，无法推进
场景 2：网络分区
├─ 协调者与部分参与者网络断开
├─ 部分参与者收不到指令，部分能收到
└─ 结果：分区两侧的参与者状态永远不一致
场景 3：参与者崩溃
├─ 参与者在 Prepare 阶段崩溃
└─ 结果：协调者等待参与者响应，无法推进（超时后可回滚） 协调者崩溃后，恢复时查 redo log：
情况 A：redo log 有 COMMIT 记录
→ 说明协调者已决定提交，发 Commit 给所有参与者
情况 B：redo log 无记录
→ 说明协调者未决定是否提交，发 Rollback
情况 C：redo log 只有 PREPARE 记录（最关键）
→ 协调者准备提交但未发 Commit
→ 协调者主动询问所有参与者："你都 Prepare OK 了吗？"
→ 都 OK → 发 Commit；任一 Fail → 发 Rollback 协调者崩溃
→ 参与者持有锁
→ 其他事务阻塞
→ 连接池耗尽
→ 服务不可用
→ 雪崩效应考察方向：
延伸递进面试题：
面试官您好，2PC 的阻塞问题是它的核心缺陷，我用三个层面来解释。 第一层：阻塞的本质。2PC 在 Prepare 阶段，参与者已经执行了本地事务（数据已写盘到 redo log），但没有提交，只是在等待协调者的 Commit 或 Rollback 指令。同时参与者持有资源锁。如果协调者在这个窗口崩溃，参与者就陷入了"不确定状态"——既不能 Commit（怕其他参与者 Fail），也不能 Rollback（可能其他参与者已提交），只能等待协调者恢复。这就是"阻塞"的本质：持有锁 + 状态未知 + 无超时机制。 第二层：阻塞的三种场景。 1. 协调者崩溃在 Prepare 之后、Commit 之前（最关键）：参与者都返回了 Prepare OK，协调者写完日志准备发 Commit 时崩溃 2. 网络分区：协调者与部分参与者网络断开，分区两侧状态永远不一致 3. 参与者崩溃：参与者在 Prepare 阶段崩溃，协调者等待响应 第三层：redo log 的恢复逻辑（这是理解"不确定"的关键）。协调者崩溃后恢复时，会查 redo log 的状态： - 有 COMMIT 记录：说明已决定提交，发 Commit - 无记录：说明未决定，发 Rollback - 只有 PREPARE 记录（最关键）：协调者准备提交但未发 Commit。此时协调者会主动询问所有参与者："你都 Prepare OK 了吗？"如果都 OK 就发 Commit，任一 Fail 就发 Rollback 这里有个关键点：参与者不能自己决定 Commit 还是 Rollback，必须等协调者。这就是"不确定状态"的根源——参与者已写盘但不知道全局结果。 业务影响：阻塞的代价是巨大的。参与者持有锁 → 其他事务阻塞 → 连接池耗尽 → 服务不可用，甚至引发雪崩效应。这就是为什么 2PC 在生产环境里慎用，尤其是 MySQL XA 这种跨库场景。 工程恢复方案有四个： 1. 超时回滚：参与者在等待指令超过 T 秒后强制回滚，牺牲一致性换可用性 2. 手动清理：工程师查 redo log 状态，手动发送 Commit/Rollback 3. 协调者故障转移：协调者集群 + 故障自动切换 4. 用 2PC 变体替代：Seata AT 一阶段提交后释放本地锁，不阻塞；TCC 用业务锁替代数据库锁 监控层面要覆盖：长事务告警、锁数量告警、事务悬挂告警。 总结一句话：2PC 阻塞的本质是"持有锁 + 状态未知 + 无超时"，根源是 CP 系统的必然代价——为了保证一致性，牺牲可用性。这也是为什么工程实践倾向于柔性事务（TCC、Saga、消息驱动）——用"最终一致"换"可用性"。
题目：2PC 协议"阻塞"问题详解
难度：high
标签：arch/distributed/transaction, distributed/2pc, difficulty/high
评分：⭐⭐☆☆☆（2/5）
练习次数：2
2PC 的阻塞发生在各自执行完成后,将自己的执行结果发送给协调者,然后等待协调者告知自己是要执行提交还是执行回滚;
如果这个阶段协调者崩溃,那么所有服务都开始进行阻塞,整个服务就完全进入了阻塞,无法正常运行
优点：
不足（high 需要精确场景与恢复）：
补充：
ℹ️ 完整讲解见上方首次记录（2026-09-23）