15

当领导者在所有追随者更新提交索引之前崩溃时会发生什么？

例如，节点 A、B、C 构成集群：

  • 只有 A 和 B 活着，A 是领导者

  • A 将一个条目（假设它是 entry1）复制到 B 并从 B 获得成功的结果

  • A 提交 entry1，并在向 B 发送心跳消息之前崩溃（这将导致 B 更新其提交索引）

  • C现在上线

我的问题是：

  • C会被选为新的领导者吗？如果是这样，那么 entry1 丢失了吗？而且，如果A以后重新加入，它的数据会不会和其他人不一致？

我知道筏规范说：

Raft 使用一种更简单的方法，它保证从选举的那一刻起，每个新领导者上都存在之前任期内所有已提交的条目，而无需将这些条目转移给领导者。

但是这里的entry1可能不被认为是committent entry？因为B没有得到老leader的确认（leader的心跳）。那么C有机会成为新的领导者吗？

  • 如果B成为新的leader，那么它应该如何处理entry1？
4

1 回答 1

16

重要的是要注意，一旦条目存储在集群中的大多数服务器上，它就会被视为已提交（技术上对此有一些警告，但对于本次对话，我们应该假设是这种情况），而不是当节点收到提交消息时从领导。如果需要提交消息来考虑已提交的条目，那么每次提交都需要两次往返——一次用于复制，一次用于提交——并且必须保留提交索引。

相反，在您的场景中，当A崩溃和C恢复时，Raft 选举算法将确保C无法被选举为领导者，因此C不会丢弃已提交的条目。只能B被选举为领导者，因为它拥有最新的日志。If Ctries to get elected leader, it will receive only a rejected vote from Bsince B's log is more up-to-date than C's (it has the committed entry). 因此，您将在实践中看到B最终将被选举并提交其上一任期的所有条目，届时该条目仍将被提交。即使B当时崩溃并A恢复，A仍然会有比现在更新的日志C因此它将再次被选为领导者。

当（不是如果）B成为领导者时，它将首先确保上一个任期的条目存储在大多数服务器上，然后再提交当前任期的任何条目。通常这是通过在新领导者任期开始时提交一个无操作条目来完成的。本质上，新的领导者提交一个无操作条目，一旦该条目存储在大多数服务器上，它就会增加其提交索引并将新的提交索引发送给所有追随者。因此，该条目不会丢失。新领导者将确保其承诺。

Raft 论文和论文中都描述了考虑将存储在大多数集群上的条目提交的注意事项。

于 2016-05-09T06:50:18.313 回答