基于Raft解决“幽灵复现”问题

3.1 关于Raft日志恢复

首先，我们聊一下Raft的日志恢复，在 Raft 中，每次选举出来的Leader一定包含已经Committed的数据（抽屉原理，选举出来的Leader是多数中数据最新的，一定包含已经在多数节点上Commit的数据），新的Leader将会覆盖其他节点上不一致的数据。虽然新选举出来的Leader一定包括上一个Term的Leader已经Committed的Log Entry，但是可能也包含上一个Term的Leader未Committed的Log Entry。这部分Log Entry需要转变为Committed，相对比较麻烦，需要考虑Leader多次切换且未完成Log Recovery，需要保证最终提案是一致的，确定的，不然就会产生所谓的幽灵复现问题。

因此，Raft中增加了一个约束：对于之前Term的未Committed数据，修复到多数节点，且在新的Term下至少有一条新的Log Entry被复制或修复到多数节点之后，才能认为之前未Committed的Log Entry转为Committed。

为了将上一个Term未Committed的Log Entry转为Committed，Raft 的解决方案如下：

Raft算法要求Leader当选后立即追加一条Noop的特殊内部日志，并