网络不可能一直处于正常情况,因为Leader或者某个Follower有可能会崩溃,从而导致日志不能一直保持一致。因此存在以下三种情况:
(1)Follower缺失当前Leader上存在的日志条目。
(2)Follower存在当前Leader不存在的日志条目。(比如旧的Leader仅仅将AppendEntries RPC消息发送到一部分Follower就崩溃掉,然后新当选Leader的服务器恰好是没有收到该AppendEntries RPC消息的服务器)
(3)Follower即缺失当前Leader上存在的日志条目,也存在当前Leader不存在的日志条目

图中最上方是日志的索引号(1-12),每个方块代表一条日志信息,方块内数字代表该日志所处的任期号。
图中当前Leader(图中最上方一行日志代表当前Leader日志)处于任期号为8的时刻。以此图说明以上三种情况存在的原因:
Follower a、b(Follower崩溃没有接收到Leader发送的AppendEntries RPC消息)满足以上说明的第一种情况。
Follower c在任期为6的时刻,Followerd在任期为7的时刻为Leader,但没有完全完成日志的发送便崩溃了,满足以上说明的第三种情况。
Follower e在任期为4的时刻,Followerf在任期为2、3的时刻为Leader,但没有完全完成日志的发送便崩溃了,同时在其他服务器当选Leader时刻也没有接收到新的Leader发送的AppendEntries RPC消息,满足第三种情况。
日志不一致的解决方案
Leader通过强迫Fol

本文探讨了在网络环境中,由于节点故障导致的日志不一致问题,包括Follower缺失、多余或混杂的日志条目。解决策略是通过Leader强制同步,覆盖Follower的冲突日志,并通过调整nextIndex值反复尝试直到一致。此外,详细分析了不同场景下的日志冲突情况及其处理方式。
最低0.47元/天 解锁文章
1381

被折叠的 条评论
为什么被折叠?



