Raft用"日志必须连续接收"的假设简化Multi-Paxos，代价是网络抖动容忍度降低

Raft协议可以理解为Multi-Paxos的一种简化实现，它最核心的简化点在于强制要求备机接受Leader日志的前提是：这条日志的LogID必须和已有日志连续（不允许出现空洞）。这一个假设一旦成立，[[幽灵复现”现象：乱序确认带来的日志诡异重现，及StartWorking日志的解决方案]]描述的乱序确认问题、以及需要靠StartWorking日志和EpochID来解决的”重确认”复杂性，在Raft里根本不会出现——因为日志天然是连续写入、连续确认的，不存在”某段日志被后来的Leader跳过、又在更后来被重新确认”这种乱序状态。但这个简化不是没有代价的：它要求日志必须严格连续地被接受，这意味着一旦某台备机因为网络抖动短暂离线、错过了一些日志，在它重新上线并把落下的日志补齐之前，它是不能参与正常投票和日志确认的——考虑A、B、C三台机器的场景，如果C临时下线错过了一部分日志，之后C重新上线但还没来得及补全日志，这时如果A、B中又有一台宕机，整个集群就会因为找不到足够的、日志完整且在线的多数派而直接停止服务。这个对比揭示了协议简化的一般代价规律：Raft用”日志连续”这个更强的前提假设，换取了协议逻辑本身的显著简化（不用处理乱序、不用EpochID），但这个更强的假设同时也收窄了协议能够容忍的故障模式——原本Multi-Paxos能够容忍的”部分节点短暂离线、日志出现空洞、之后再补齐”这类场景，在Raft里会因为不满足”日志连续”这个前提而暂时无法正常参与服务，网络抖动的容忍度因此比Multi-Paxos更低。