我试图了解 three-phase commit避免阻塞
考虑以下两种失败情况:
场景 1:在第 2 阶段，协调器向所有群组发送 preCommit 消息，并且已从群组 A 之外的所有群组获得确认。网络问题阻止群组 A 接收协调器的 preCommit 消息。队列 A 等待 preCommit 消息超时并选择中止。然后协调者和队列 A 都崩溃了。
场景 2:协议(protocol)到达阶段 3。协调器向队列 A 发送一个 doCommit 消息。但在它可以发送更多的 doCommit 消息之前，协调器崩溃了。群组 A 提交其部分事务然后崩溃。
据我所知，其余队列在场景 1 和场景 2 结束时具有完全相同的状态。因此，当恢复协调员介入时，它如何从剩余队列中找出我们是否处于场景 1 并中止或我们在场景 2 中并提交，从而避免阻塞？
最佳答案
三阶段提交并不神奇。它比两阶段提交更具弹性。特别是，3PC 对单点故障具有弹性，但不是所有类型的多点故障。问题中的两种情况都提出了两点故障。换句话说，问题的前提是错误的；它对 3PC 的要求超过了它的能力。
为了进一步阅读，这是一篇关于该主题的论文摘要中的一句话，Analysis and Verification of Two-Phase Commit & Three-Phase Commit Protocols, by Muhammad Atif ，激发你的食欲:
We also apply our method to its “amended” variant, the Three-Phase Commit Protocol (3PC) and prove it to be erroneous for simultaneous site failures
我发现这篇论文为文献提供了一个立足点。如果您想深入研究，关于这个主题的内容并不多。
关于distributed-transactions - 三阶段提交如何避免阻塞？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21424962/