在这种情况下，当我采用 Raft 的“从不通过计算副本来提交以前条款的日志条目”规则时，这是否会导致真正的问题？

Question

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

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

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

   Raft 永远不会通过计数来提交上一期的日志条目 复制品。只有领导者当前任期的日志条目是 通过计算副本提交；

10. 假设没有更多来自客户端的LogEntrys 可以复制，所以LogEntry X 仍然未提交。

我的问题是：

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

Answer 1

1. 否

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

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

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