当跟随者在 raft 中失败时，领导者重试的详细信息

Question

我已经阅读了关于 raft 的paper，我对此感到困惑

如果追随者崩溃或运行缓慢，或者网络数据包丢失， 领导者无限期地重试 AppendEntries RPC（即使它已经 响应客户端）直到所有关注者最终存储所有日志 条目。

写在5.3 Log replication部分的开头。

为了让我的困惑更清楚，我把它分成两个问题。

---

问题 1. 领导者是否应该在以下所有三种失败情况下重试？

1. reply false if term
2. 如果日志在 prevLogIndex 中不包含其术语与 prevLogTerm 匹配的条目，则回复 false（在图 2 中）
3. rpc 错误或超时

---

问题2.如果leader在某些情况下需要重试，leader进程是否会阻塞直到所有follower都回复成功？

---

以下是我的尝试：

• 在第一次失败的情况下，领导者不需要重试。
• 在第二次失败的情况下，leader应该重试，并调整follower的nextIndex，直到follower回复成功。在接受下一个客户端请求之前，领导者也会被阻止。
• 在第三种失败情况下，领导者不需要重试，我们可以在下一次客户端请求时附加失败条目。

Answer 1

这句话只描述了当跟随者出于任何原因（例如跟随者问题或网络问题）没有给出响应时，领导者将重试。

在您在问题 1 下列出的场景 1 和 2 中，追随者确实会对领导者做出拒绝回应，因此这与您最初的困惑不同。 现在来回答在这些情况下会发生什么：

1. 如果领导者的当前任期 X
2. follower 拒绝 AppendEntries RPC，因为 follower 不包含 prev 索引处的日志。在这种情况下，领导者应该强制追随者在添加新条目之前复制领导者的日志。该机制在处理不一致部分中进行了描述。

问题 2 的答案很简单：当多数人返回成功时，领导者可以继续并更新状态机。重试剩余的追随者是出于数据一致性的目的，它不会减慢系统速度。