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