Part 09：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-持久化的状态和服务器重启）

Part 09：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-持久化的状态和服务器重启）

3.8 Persisted state and server restarts（持久化的状态和服务器重启）

Raft算法中的服务器需要持久化足够的信息到可靠存储设备上以保证服务器可以安全的重启。每个服务器都会持久化其当前所属的term和选票信息。这样可以防止这个服务器在某个term中进行多次投票（尤其是投票给不同的Candidate），或者使用无效的Leader的log entry来覆盖现有的Leader的log entry。每个服务器还会在被评估已提交的log entry之前持久化存储新的log entry，这样可以防止已提交的log entry丢失或者在服务器重启时导致其变成未提交。

    其它的信息在服务器重启后丢失是安全的，也就是不影响Raft算法的正确性，因为这些信息都可以重新生成。最有趣的就是commit index信息，commit index可以在重启时被初始化为0。即使所有的服务器在同一时刻重启成功，commit index仅仅会暂时的落后于其真实值。一旦一个Leader被选出并且能够commit新的log entry，commit index就会增长，并且很快就会将commit index传播给其它的Follower。

    状态机可以是易失的也可是持久化的。易失的状态机可以通过重放log entry进行恢复（在重放最近的快照后就可以恢复，见第5章）。一个持久化的状态机，已经在重启前apply大部分的log entry了。为避免重放已经持久化的log entry，**最后一个已经被apply的log entry的index需要被持久化**。

    如果某个服务器丢失了其持久化的状态，它就不能以之前的ID再安全的重新加入集群。这样的服务器可以以一个新的ID并通过第4章中所述的成员变更方法加入到集群。如果大部分的服务器丢失了其持久化的状态，那么log entry就会丢失了，集群就无法安全带的继续运行了，这时候，为了保证集群继续运行，那么系统管理员就要在容忍数据丢失的前提下容许集群继续运行。

<< 上一章：Raft算法-Follower和Candidate宕机处理机制
下一章：Raft算法-时间和可用性 >>