两阶段提交如何防止最后一秒失败？

我正在研究两阶段提交如何在分布式事务中工作。据我了解，在该阶段的最后部分，事务协调器会询问每个节点是否准备好提交。如果每个人都同意，那么它会告诉他们继续努力。

是什么防止以下故障？

1. 所有节点均响应已准备好提交
2. 事务协调器告诉他们“继续并提交”，但是其中一个节点崩溃，然后收到此消息
3. 所有其他节点均成功提交，但现在分布式事务已损坏
4. 据我了解，当崩溃的节点返回时，其事务将被回滚（因为它从未收到提交消息）

我假设每个节点都在运行一个普通的数据库，该数据库对分布式事务一无所知。我错过了什么？

不，不指示它们回滚，因为在原始发布者的场景中，某些节点已经提交。发生的事情是当崩溃的节点变为可用时，事务协调器告诉它再次提交。

因为该节点在“准备”阶段做出了积极响应，所以即使它从崩溃中恢复过来，也要求它能够“提交”。

总结大家的答案：

1. 人们不能将普通数据库与分布式事务一起使用。数据库必须明确支持事务协调器。

2. 不指示节点回滚，因为某些节点已经提交。发生的事情是当崩溃的节点返回时，事务协调器告诉它完成提交。

否。第4点不正确。每个节点都在稳定的存储中记录了它能够提交或回滚该事务，因此即使在崩溃时也可以按照命令执行。当崩溃的节点恢复正常运行时，它必须意识到它的事务处于预提交状态，恢复所有相关的锁或其他控件，然后尝试联系协调器站点以收集事务的状态。

仅当崩溃的节点再也不会恢复时才会出现问题（然后其他一切都认为事务正常，或者当崩溃的节点恢复时就会发生）。

两阶段提交并不是万无一失的，只是设计为可以在99％的情况下使用。

“该协议假设每个节点上都有一个预写日志来稳定存储，没有节点永远崩溃，该预写日志中的数据在崩溃中永远不会丢失或损坏，并且任何两个节点都可以通信彼此之间。”

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

有两阶段提交来解决问题的方法很多。它们几乎都作为Paxos三相提交算法的某些变体出现。在基于Paxos的Google上设计Chubby Lock服务的Mike Burrows说，在我看到的一次演讲中，有两种类型的分布式提交算法-“ Paxos和不正确的”。

当崩溃的节点重新唤醒时，可以做的一件事是说“我从未听说过该事务，是否应该提交？” 交给协调员，协调员将告诉投票结果。

请记住，这是一个更普遍的问题的示例：崩溃的节点在恢复之前可能会丢失许多事务。因此，非常重要的是，恢复后应在可用之前与协调器或另一个副本进行对话。如果节点本身无法确定它是否已崩溃，那么事情将涉及更多但仍然易于处理。

如果将仲裁系统用于数据库读取，则不一致将被掩盖（并使数据库本身知道）。