为何未存储多数服务器条目仍能当选RAFT集群Leader？

核心原因：Raft选举仅校验日志的最终完整性，而非全量条目匹配 #

Raft的选举规则只要求候选节点的日志满足「至少和半数以上投票节点的日志一样新」——具体判断标准是：

• 候选节点最后一条日志的任期号大于投票节点的，或者
• 两者最后一条日志的任期号相同，但候选节点的日志长度更长

这个规则能保证当选的Leader一定拥有所有已提交的日志条目，但不保证它拥有所有已被多数节点保存但未提交的条目。这就是你提到的场景出现的原因：有些条目已经被多数节点存储，但因为还没被提交（比如原Leader复制完多数后还没来得及提交就崩溃），候选节点可能没同步到这些条目，但只要它的日志最终状态符合选举条件，就能拿到半数以上选票当选。

为什么这是合理的？ #

你担心的「候选节点状态不最新」其实是个误解：Raft的设计目标是保证已提交的日志一定不会丢失，而未提交的日志本身就不具备一致性承诺——它们可能被后续的Leader覆盖。

当这类「日志不全」的Leader当选后，Raft会通过日志复制流程自动补全缺失的条目：Leader会向其他节点同步自己的日志，同时也会接收其他节点上自己缺失的条目，最终让所有节点的日志达成一致。

另外，Kuujo提到的「Leader必须提交当前任期的一个条目才能确认过往任期条目已提交」，就是为了避免这类场景下的一致性风险——比如某个未提交的旧任期条目已经被多数节点存储，但新Leader没拿到，这时候直接提交旧条目可能导致集群分裂，而提交一个当前任期的新条目后，就能连带确认所有之前的条目都已被多数节点认可。

没错。Leader拥有所有已提交的先前条目是选举算法的特性，但实际的commitIndex完全不参与选举算法。事实上，Leader完全可能在未存储部分已被多数服务器保存的条目的情况下当选。这就是为什么提交不能仅通过副本计数来确定，也是为什么Leader必须提交当前任期的一个条目，才能确认过往任期的条目已提交。有关这一点的解释请参阅Raft论文中的图8。—— kuujo，2016年5月17日21:35

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