问题描述
我已经阅读了paper关于木筏的信息，我对此感到困惑
如果追随者崩溃或运行缓慢，或者网络数据包丢失，则 领导者无限期地重试AppendEntries RPC（即使已 响应客户端），直到所有关注者最终存储了所有日志 项。
写在5.3 Log replication部分的开头。
为使我的困惑更加清楚，我将其分为两个问题。
问题1.领导者是否应在以下所有三种失败情况下重试？
- 如果条件
- 如果日志在prevLogIndex中不包含条目与prevLogTerm匹配的条目，则为false（图2）
- rpc错误或超时
问题2.如果领导者在某些情况下应重试，领导者流程是否会阻塞，直到所有关注者都回复成功？
以下是我的尝试：
- 在第一个失败的情况下，不需要领导重试。
- 在第二次失败的情况下，领导者应重试并调整关注者的nextIndex，直到关注者回复成功为止。另外，领导者将在接受下一个客户请求之前被阻止。
- 在第三种失败情况下，领导者无需重试，我们可以在下一个客户请求时附加失败条目。
解决方法
引号仅描述领导者将在关注者出于任何原因（例如关注者问题或网络问题）未给出回应时重试。
在问题1下列出的情况1和2中，追随者的确拒绝了领导者的回应，因此与您最初的困惑有所不同。 现在回答在这些情况下会发生什么：
- 如果领导者的当前任期X
- 关注者拒绝AppendEntries RPC，因为关注者在上一个索引中不包含日志。在这种情况下，领导者应强制追随者在添加新条目之前复制领导者的日志。该机制在处理不一致部分中进行了说明。
问题2的答案非常简单：当大多数人返回成功时，领导者可以继续并更新状态机。重试其余的跟随者是出于数据一致性的目的，不会降低系统的速度。