Raft算法系列教程4：日志不一致的解决

最新推荐文章于 2023-12-13 22:00:00 发布

计算机小书童

最新推荐文章于 2023-12-13 22:00:00 发布

阅读量1k

点赞数 3

文章标签：分布式

本文链接：https://blog.youkuaiyun.com/FastText/article/details/111998686

版权

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

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

网络不可能一直处于正常情况，因为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消息，满足第三种情况。

<

最低0.47元/天解锁文章