Part 09：Raft論文翻譯-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基礎(chǔ)Raft-持久化的狀態(tài)和服務(wù)器重啟）

3.8 Persisted state and server restarts（持久化的狀態(tài)和服務(wù)器重啟）

Raft算法中的服務(wù)器需要持久化足夠的信息到可靠存儲(chǔ)設(shè)備上以保證服務(wù)器可以安全的重啟。每個(gè)服務(wù)器都會(huì)持久化其當(dāng)前所屬的term和選票信息。這樣可以防止這個(gè)服務(wù)器在某個(gè)term中進(jìn)行多次投票（尤其是投票給不同的Candidate），或者使用無(wú)效的Leader的log entry來(lái)覆蓋現(xiàn)有的Leader的log entry。每個(gè)服務(wù)器還會(huì)在被評(píng)估已提交的log entry之前持久化存儲(chǔ)新的log entry，這樣可以防止已提交的log entry丟失或者在服務(wù)器重啟時(shí)導(dǎo)致其變成未提交。

    其它的信息在服務(wù)器重啟后丟失是安全的，也就是不影響Raft算法的正確性，因?yàn)檫@些信息都可以重新生成。最有趣的就是commit index信息，commit index可以在重啟時(shí)被初始化為0。即使所有的服務(wù)器在同一時(shí)刻重啟成功，commit index僅僅會(huì)暫時(shí)的落后于其真實(shí)值。一旦一個(gè)Leader被選出并且能夠commit新的log entry，commit index就會(huì)增長(zhǎng)，并且很快就會(huì)將commit index傳播給其它的Follower。

    狀態(tài)機(jī)可以是易失的也可是持久化的。易失的狀態(tài)機(jī)可以通過(guò)重放log entry進(jìn)行恢復(fù)（在重放最近的快照后就可以恢復(fù)，見(jiàn)第5章）。一個(gè)持久化的狀態(tài)機(jī)，已經(jīng)在重啟前apply大部分的log entry了。為避免重放已經(jīng)持久化的log entry，**最后一個(gè)已經(jīng)被apply的log entry的index需要被持久化**。

    如果某個(gè)服務(wù)器丟失了其持久化的狀態(tài)，它就不能以之前的ID再安全的重新加入集群。這樣的服務(wù)器可以以一個(gè)新的ID并通過(guò)第4章中所述的成員變更方法加入到集群。如果大部分的服務(wù)器丟失了其持久化的狀態(tài)，那么log entry就會(huì)丟失了，集群就無(wú)法安全帶的繼續(xù)運(yùn)行了，這時(shí)候，為了保證集群繼續(xù)運(yùn)行，那么系統(tǒng)管理員就要在容忍數(shù)據(jù)丟失的前提下容許集群繼續(xù)運(yùn)行。

<< 上一章：Raft算法-Follower和Candidate宕機(jī)處理機(jī)制
下一章：Raft算法-時(shí)間和可用性 >>