Part 10：Raft論文翻譯-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基礎(chǔ)Raft-時間和可用性）
3.9 Timing and Availability（時間和可用性）
我們對Raft的要求之一是安全不能取決于時間：系統(tǒng)不能僅僅因為某些事件發(fā)生得比預(yù)期的更早或更晚而產(chǎn)生不正確的結(jié)果。然而，可用性（系統(tǒng)及時響應(yīng)客戶端的能力）必須不可避免地取決于時間。例如，如果消息交換花費的時間比兩次服務(wù)器崩潰之間的常規(guī)時間要長，Candidate將不會保持這個狀態(tài)足夠長的時間以贏得選舉（Candidate的超時機制導(dǎo)致它不能等很久來確定是否勝選/敗選）；沒有一個穩(wěn)定的Leader，Raft就無法取得進展。

Leader選舉是Raft選舉的關(guān)鍵模塊之一，這個模塊嚴(yán)重依賴于時間。Raft能夠選出Leader并保持這個Leader穩(wěn)定，如果系統(tǒng)中的時間滿足下面的要求：

broadcastTime << electionTimeout << MTBF (“<<”是遠小于的意思)
上述的不等式中，broadcastTime是某個服務(wù)器向系統(tǒng)中其它服務(wù)器并行發(fā)送RPC請求并收到回復(fù)所需的平均時間；electionTimeout是選舉超時時間；MTBF是單個服務(wù)器兩次故障之間的平均時間。broadcastTime應(yīng)該比electionTimeout小一個數(shù)量級以保證Leader有足夠的的時間來收集Follower的心跳信息；在所描述的隨機選舉超時機制中，隨機的超時時間也能保證分裂的選舉以小概率的機會出現(xiàn)。electionTimeout應(yīng)該比MTBF時間小數(shù)個數(shù)量級以保證系統(tǒng)能正常運行。當(dāng)Leader宕機/失效時，系統(tǒng)中難免會通過隨機超時來進行新一輪的選舉，我們希望這個選舉過程盡可能短。

broadcastTime和MTBF底層系統(tǒng)來提供的系統(tǒng)性保障，但是electionTimeout是我們可以控制的。Raft的RPC要保證接收者有足夠的的時間來存儲相關(guān)信息，這個時間大約是0.5-20ms，也取決于具體的持久化設(shè)備的性能。所以，Raft將選舉超時時間設(shè)定在了10-500ms之間進行取值。典型的MTBF是幾個月或者更久，這很好的滿足了Raft對系統(tǒng)時間的要求。第9章說明了詳細(xì)如何設(shè)置選舉超時時間和這個時間對可用性、選舉性能的影響。

<< 上一章：Raft算法-持久化的狀態(tài)和服務(wù)器重啟
下一章：Raft算法-Leader轉(zhuǎn)換 >>