我试图了解三阶段提交如何避免阻塞
考虑以下两种失败情况：
场景 1：在第 2 阶段，协调器向所有群组发送 preCommit 消息，并且已从群组 A 之外的所有群组获得确认。网络问题阻止群组 A 接收协调器的 preCommit 消息。队列 A 等待 preCommit 消息超时并选择中止。然后协调者和队列 A 都崩溃了。
场景 2：协议到达阶段 3。协调器向队列 A 发送一个 doCommit 消息。但在它可以发送更多的 doCommit 消息之前，协调器崩溃了。群组 A 提交其部分事务然后崩溃。
据我所知，其余队列在场景 1 和场景 2 结束时具有完全相同的状态。因此，当恢复协调员介入时，它如何从剩余队列中找出我们是否处于场景 1 并中止或我们在场景 2 中并提交，从而避免阻塞？
三阶段提交并不神奇。它比两阶段提交更具弹性。特别是，3PC 对单点故障具有弹性，但不是所有类型的多点故障。问题中的两种情况都提出了两点故障。换句话说，问题的前提是错误的；它对 3PC 的要求超过了它的能力。
为了进一步阅读，这里是Muhammad Atif 撰写的关于两阶段提交和三阶段提交协议的分析和验证主题的论文摘要中的一句话，以激发您的兴趣：
我们还将我们的方法应用于其“修正”变体三阶段提交协议 (3PC)，并证明它对于同时发生的站点故障是错误的
我发现这篇论文为文献提供了一个立足点。如果您想深入研究，关于这个主题的内容并不多。
在两阶段提交中，协调者向所有参与者（节点）发送一条准备消息并等待他们的回答。然后，协调员将他们的答案发送到所有其他站点。在提交或中止事务之前，每个参与者都会等待协调者的这些回答。
两阶段提交协议也有局限性，因为它是一个blocking protocol. 例如，参与者在等待来自协调者的消息时会阻塞资源进程。如果由于任何原因失败，参与者将继续等待并且可能永远不会解决其事务。因此，资源可能会被无限期地阻塞。另一方面，协调者也会在等待参与者回复时阻塞资源。在这种情况下，如果没有收到参与者的确认，协调者也可以肯定地阻止。
但是，三阶段协议引入了第三阶段，称为pre-commit. 这样做的目的是“消除已提交并正在等待来自协调器的全局中止或提交消息的参与者的不确定期。
When receiving a pre-commit message, participants know that all others have voted to commit.
If a pre-commit message has not been received the participant will abort and release any blocked resources.
在场景 1 中：
恢复期间：除 A 之外的所有群组都将处于 PRECOMMIT 状态。这告诉恢复节点所有群组都已投票支持该提交并继续前进。所以 A 和 Coordinator 应该处于 PRECOMMIT 状态。由于这是一个非最终状态，交易被中止。
在场景 2 中：
恢复期间：除 A 之外的所有群组都将处于 PRECOMMIT 状态。这告诉恢复节点所有群组都已投票支持提交并继续前进。但由于 A 收到 doCommit 消息，它处于 COMMITTED 状态。如果没有发生崩溃，恢复将要求所有群组提交，因为至少有一个群组已经提交. 由于发生崩溃（A 崩溃），恢复节点没有看到具有已提交状态的实时群组，因此它推断没有群组收到 doCommit 消息。因此，事务将被中止，并且将要求所有群组释放资源。
当 A 从崩溃中返回并开始恢复时，它会发现所有其他队列都中止了事务，它也将中止事务。
帮助我理解非阻塞属性的事情是意识到在第一轮消息之后，两个协议基本上处于相同的状态。所有参与者都同意他们可以提交并正在等待确认这样做。
现在，考虑参与者在第一轮回答“ok to commit”后所知道的内容。
继续前进，在 3PC 中的第二轮消息和确认之后，我们保证所有参与者都知道小组决定是提交。
这意味着在 3PC 中永远不会有参与者执行另一个参与者没有预料到的提交操作。
