我正在阅读维基百科 (http://en.wikipedia.org/wiki/Three-phase_commit_protocol) 上的 3 阶段提交协议，我想到了一个 3PC 将失败的场景：
假设有两个参与者 A 和 B 以及一个协调者 C：
1)C 向 A 发送了 precommit 消息，在它向 B 发送 precommit 消息之前，A 和 C 同时失败。 2）事务现在重新启动，B 最终中止它，因为 A 没有回复。3）A 提交事务，因为它已经收到了 precommit 消息。
这不也是 2PC 原本应该解决的 2PC 问题吗？ 3PC是如何解决问题的？我错过了什么。谢谢。
【问题讨论】：
更新：
参与者在收到来自协调者的 doCommit 消息之前是否不提交？
参与者收到preCommit消息后，会先等待，如果超时，则继续提交。
如果协调者在发送 precommit 消息后失败，并且至少有一个参与者具有 precommit 消息，则系统中的其余部分可以继续提交，因为他们已经知道系统上的状态。 em>
是的，一旦新的 coordinator 看到他们是已经收到 preCommit 消息的参与者，它会重新向其他参与者发送 preCommit 消息。
【讨论】：
如果协调器在任何时候崩溃，恢复节点可以接管事务并从任何剩余的副本中查询状态。如果已提交事务的副本崩溃，我们知道每个其他副本都收到了“准备提交”消息（否则协调器不会移动到提交阶段），因此恢复节点将是能够确定事务能够被提交，并安全地引导协议完成。如果任何副本向恢复节点报告它没有收到'准备提交'，恢复节点将知道事务在任何时候都没有提交副本，因此将能够悲观地中止或从头开始重新运行协议。
--引用自http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/
所以我认为新的coordinator会查询cohorts的状态，只有当所有live的cohort都收到pre-commit消息后，新coordinator才会发送do-commit消息；否则，交易将被中止。
【讨论】：
3PC 只容忍单点故障，不能容忍多点故障。实际上，要确保 3PC 正常工作，必须满足以下三个条件：
没有网络故障（即没有网络分区，如果目标机器正在工作（没有崩溃），每条消息都会在超时之前到达目标）
最多有一个参与者会失败（崩溃）。准确地说，如果协调器失败（崩溃），所有群组都不能失败
参与者机器可以区分超时和失败（这不是微不足道的，考虑一下它什么时候崩溃（即断电）超时后，它无法向持久存储写入任何内容以提醒自己它是恢复时超时而不是崩溃）
这些条件都不实用。所以我不认为3PC可以在现实世界中实现。
【讨论】：