我目前正在研究2阶段和3阶段提交。
3PC协议试图通过添加一个额外的阶段preCommit来消除2PC协议的系统阻塞问题。正如提到的这里
根据这篇post，如果协调器在任何时候崩溃，恢复节点可以接管事务并从任何剩余副本查询状态。例如，如果任何剩余副本回复恢复节点，它处于预提交状态，那么恢复节点将知道失败的协调器已发送预提交消息，并且所有副本已同意提交。
我的问题是，为什么两阶段提交不能做同样的事情？当协调器失败时，恢复节点查询那些剩余节点并看到其中任何一个已经处于 Commit 阶段？
我已经阅读了服务器帖子，但我仍然不知道三阶段提交到底要解决什么问题以及如何解决？
请帮忙！
恢复节点可以查询剩余节点，但是如果在恢复节点收集所有消息之前另一个节点崩溃了会发生什么？
在每个参与者确认每条消息之前，两阶段提交协议无法继续。
以下场景的两阶段等待和阻塞资源。
1-协调器在启动准备阶段后失败，选举新的协调器。但是，如果在恢复节点收集第一阶段的所有消息之前另一个节点崩溃，则协议无法继续。 如果所有其他参与节点都同意提交，但新崩溃的节点可能打算中止。因此恢复节点不能将该决策称为提交。这个论点反之亦然。
2-同样，如果在协调器收到参与者的响应之前参与者在第 1 阶段失败，也会发生同样的情况。因为协调器不知道失败节点的结果，因此无法继续提交或中止共识。
3-如果参与者或协调者和参与者节点在第 2 阶段失败，协调者无法决定是否提交事务。
三阶段提交的相同场景。
1-在准备阶段，如果参与者没有及时收到协调员的消息，则会中止。如果协调器没有收到任何参与者的消息，它会向所有参与者发送中止消息。（实际上，在使用两阶段提交时可以采取相同的方法，但两阶段提交协议在每个参与者确认每条消息之前无法继续。）
2- 准备阶段采用相同的方法。如果协调器在等待参与者时超时 - 假设它崩溃了，告诉每个人中止。
3-协调者不知道参与者是在提交之后还是提交之前失败的。因此协调者无法主动决定事务是否提交。所以与此步骤类似的这一步也类似于两阶段提交协议。
那么现在为什么还有额外的步骤呢？ 其他人声称以下
“这样做的目的是‘消除已提交并正在等待协调器发出的全局中止或提交消息的参与者的不确定期。”
我不同意这种说法。在我看来，这只是一个额外的阶段，让协调器有机会在协调器发生故障时安全地回滚整个操作。
关于这个主题已经写了一些令人困惑的文章。这些是我的结论，我总是愿意审查我的答案。