Part 08:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(基础Raft-Follower和Candidate宕机处理机制)

3.7 Follower and Candidate Crashes(Follower和Candidate宕机处理机制)

到现在为止,我们关注的还是Leader的失效处理。Follower和Candidate的失效处理相对来说比较简单,他们的处理用的是同样的方法。如果一个Follower或者Candidate失效了(或者与Leader之间的网络故障了),那么未来的RequestVote和AppenEntries RPC消息都将收不到了。Raft通过固定次数的重试来解决这个问题,如果失效的服务器很快恢复,那RPC会成功;如果某个服务器在完成RPC操作后,回复Leader消息前失效了,那么它在恢复后会收到同样的RPC请求。Raft的RPC具有幂等性,所以不会产生什么副作用。例如,如果一个Follower接收到了AppenEntries RPC,而且这个Follower已经保存了相应的log entry,那么这个Follower就会忽略这个RPC请求。

<< 上一章:Raft算法-安全性
下一章:Raft算法-持久化的状态和服务器重启 >>

你可能感兴趣的:(Part 08:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(基础Raft-Follower和Candidate宕机处理机制))