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

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 三阶段提交算法的变体。在 Google 设计基于 Paxos 的 Chubby 锁服务的 Mike Burrows 在我看到的一次讲座中说，有两种类型的分布式提交算法——“Paxos 和不正确的”。

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

请记住，这是一个更普遍问题的示例：崩溃的节点在恢复之前可能会错过许多事务。因此，非常重要的是，在恢复后，它应该与协调器或另一个副本通信，然后再使其可用。如果节点本身无法判断它是否已经崩溃，那么事情就会变得更加复杂，但仍然可以处理。

如果您使用仲裁系统进行数据库读取，则不一致性将被屏蔽（并使数据库本身知道）。