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

Question

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

是什么阻止了以下失败？

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

我假设每个节点都运行一个对分布式事务不了解的普通数据库。我错过了什么？

Answer 1

不，他们没有被要求回滚，因为在原始海报的情况下，一些节点已经提交。当崩溃的节点变得可用时，事务协调器会告诉它再次提交。

由于节点在“准备”阶段得到积极响应，因此即使从崩溃中恢复，也需要能够“提交”。

Answer 2

总结每个人的答案：

1. 不能将普通数据库用于分布式事务。数据库必须明确支持事务协调器。

2. 未指示节点回滚，因为某些节点已提交。当崩溃的节点返回时，事务协调器会告诉它再次提交。

Answer 3

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

问题只发生在崩溃的节点永远不会恢复的情况下（然后其他一切都认为交易正常，或者当崩溃的节点回来时）。

Answer 4

两阶段提交并非万无一失，只是在99％的时间内工作。

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

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

Answer 5

有两种方法可以通过两阶段提交来解决问题。几乎所有这些都成为Paxos三阶段提交算法的一些变体。设计谷歌Chubby锁定服务的Mike Burrows基于Paxos，他说在我看到的一个讲座中有两种类型的分布式提交算法 - “Paxos和不正确的” -

崩溃的节点可以做的一件事，当它重新唤醒时，说“我从来没有听说过这个交易，它应该被提交吗？”协调员，它将告诉它投票是什么。

请记住，这是一个更普遍的问题的示例：崩溃的节点在恢复之前可能会丢失许多事务。因此，非常重要的是，在恢复之后，应该先让协调员或其他副本与自己联系。如果节点本身无法判断它是否已经崩溃，那么事情就会变得更加复杂，但仍然易于处理。

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