0

我目前正在自己​​实现 Raft 共识算法，我遇到了以下问题。考虑有 4 个节点（A、B、C 和 D），因此可以提交超过 2 票的日志条目。现在我们启动集群并让 Leader A 用term = 0. 然后发生以下事情：

  1. 从动 B/D 断开。
  2. 领导者 A 创建LogEntryX。
  3. 领导者 A 尝试复制到所有节点并最终失败，因为只有 2 个节点（A 和 C）。
  4. 节点 B 重新连接并超时，它使用 new 开始选举term = 1。
  5. 节点 A 失去了领导地位，因为它收到了节点 B 的RequestVoteRPC。
  6. Node B can't win the election, because it has no LogEntryX. So there are no Leader in the cluster.
  7. 节点A超时，再次被选为Leader。
  8. Leader A 成功将 X 复制LogEntry到 B。

  9. 现在节点 A/B/C 具有完全相同的LogEntryX，即(index = 0, term = 0). 然而，根据 Raft 论文，Leader A 不能提交 X，尽管它是自己生成的，并且多数同意 X。

    Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交；

  10. 假设不再有LogEntry来自客户端的 s 来复制，所以LogEntryX 保持未提交。

我的问题是：

  1. 这是一个真正的问题吗？
  2. 有一些解决方案吗？事实上，已经有一些关于 SoF 的帖子强调了这条规则的重要性。在这篇文章中，似乎说我们可以创建 X 的副本 Y，并复制 Y。它是否有效，或者是否存在通用解决方案？
4

1 回答 1

2

  1. 不

  2. 是的。在第 13 页的牛皮纸中，您有以下内容：

领导者完整性属性保证领导者拥有所有已提交的条目，但在其任期开始时，它可能不知道那些是哪些。要找出答案，它需要从其任期内提交一个条目。Raft 通过让每个领导者在其任期开始时向日志中提交一个空白的 no-op 条目来处理这个问题

在您的情况下，在第 7 步之后，A将创建一个NoOpLog 条目，它将成功复制它，提交它，因此所有以前的条目都将被提交。

于 2019-02-27T16:29:24.043 回答