两阶段提交如何防止最后一次失败？
我正在研究在分布式事务中两阶段提交是如何工作的。 我的理解是，在该阶段的最后阶段，事务协调器询问每个节点是否准备好提交。 如果大家都同意的话，那就告诉他们继续前进吧。
什么阻止了以下失败？
- 所有节点都回应他们准备提交
- 事务协调员告诉他们“继续并提交”，但其中一个节点在收到此消息之前崩溃
- 所有其他节点提交成功，但现在分布式事务已损坏
- 这是我的理解，当崩溃的节点回来，它的事务将被回滚（因为它从来没有得到提交消息）
我假设每个节点正在运行一个普通的数据库，不知道任何有关分布式事务。 我错过了什么？
不，他们没有被指示回滚，因为在原来的海报的情况下，一些节点已经提交。 发生什么事是当崩溃的节点变得可用时，事务协调器告诉它再次提交。
由于节点在“准备”阶段中作出了积极响应，即使从崩溃回来，也需要能够“提交”。
第4点不正确。 每个节点都在稳定的存储器中logging它能够提交或回滚事务，以便即使在崩溃时也能按照指令执行操作。 当崩溃的节点恢复时，它必须意识到它有一个处于预先提交状态的事务，恢复任何相关的锁或其他控制，然后尝试联系协调器站点来收集事务的状态。
只有当崩溃的节点不再回来时（所有其他事情认为事务正常，或者当崩溃的节点回来时），问题才会发生。
总结每个人的答案：
-
不能使用普通的数据库和分布式事务。 数据库必须明确支持事务协调器。
-
节点没有被指示回退，因为一些节点已经提交。 会发生什么情况是，当崩溃的节点回来时，事务协调器告诉它再次提交。
两阶段提交不是万无一失的，只是在99％的时间内工作。
“该协议假定在每个节点上有一个预先写好日志的稳定存储，没有节点永远崩溃，预写日志中的数据不会在崩溃中丢失或损坏，并且任何两个节点都可以通信彼此“。
有两种方式来攻击两阶段提交的问题。 几乎所有这些都是Paxos三阶段提交algorithm的变体。 devise基于Paxos的Google Chubbylocking服务的Mike Burrows说，在我看到的演讲中，有两种types的分布式提交algorithm – “Paxos和不正确的”。
有一件事情在崩溃的时候可以做，当它重新出现的时候，就会说：“我从来没有听说过这个交易，是否应该承诺呢？” 向协调员，这将告诉它什么投票。
请记住，这是一个更为普遍的问题的示例：崩溃的节点在恢复之前可能会错过许多事务。 因此，在恢复之后，它应该与协调者或另一个副本进行交谈，然后才能使用。 如果节点本身不知道它是否已经崩溃，那么事情就会变得更加复杂，但仍然很容易处理。
如果您使用仲裁系统进行数据库读取，则不一致性将被屏蔽（并使数据库本身知晓）。
