Raft算法中Leader选举与AppendEntries拒绝场景的三类技术问题

论文参考（5.2节原文） #

While waiting for votes, a candidate may receive an AppendEntries RPC from another server claiming to be leader. If the leader’s term (included in its RPC) is at least as large as the candidate’s current term, then the candidate recognizes the leader as legitimate and returns to follower state. If the term in the RPC is smaller than the candidate’s current term, then the candidate rejects the RPC and continues in candidate state.

场景时间线 #

• 所有节点处于Term 1，S1为Leader
• S2短暂间歇性断开连接
• S2成为Term 2的候选者，尝试发送RequestVotes（暂未被其他节点接收）
• S2等待投票期间，网络连接恢复
• S2收到来自Term 1的Leader S1的AppendEntries请求

问题解答 #

1. 处于Term 2的候选者S2是否会因S1的Term更旧而拒绝其AppendEntries请求？
   会。根据论文规则，候选者收到的AppendEntries RPC任期小于自身当前任期时，会拒绝请求并保持候选者状态。S2当前任期为2，S1的请求任期是1，符合拒绝条件，因此S2会拒绝该请求，继续以候选者身份运行。

2. 领导者S1会因AppendEntries请求被拒绝而退位吗？
   会。S1收到拒绝响应时，会从响应中获取到S2的Term 2（Raft中节点拒绝RPC时会返回自身当前任期），该任期大于S1的Term 1，因此S1会立即将自身任期更新为2，同时从领导者状态退化为追随者。

3. 节点S3会作何反应，它会投票给S2吗？
   会投票给S2。只要S3仍处于Term 1且未在该任期内投过票，当它收到S2的Term 2的RequestVotes请求时，由于S2的任期更高，且S2仅短暂断连，日志与S3保持一致（满足日志完整性要求），S3会给S2投赞成票。

内容的提问来源于stack exchange，提问作者George Costanza