raft協議初識

什麼是Raft協議？

• 對於分散式系統而言，與單機系統相比優勢之一就是有更好的容錯性。比如當一臺機器上的磁碟損壞，資料丟失，可以從另一臺機器上的磁碟恢復（分散式系統會對資料做備份），叢集中某些機器當機，整個叢集還可以對外提供服務。實現的方法很自然的想到的就是備份。
• 一個系統的工作模式：接受客戶端的command，系統進行處理，將處理的結果返回給客戶端。由此可見，系統裡的資料可能會因為command而變化。
• 實現備份的做法之一就是複製狀態機（Repilcated State Machine，RSM），它有- 一個很重要的性質——確定性（deterministic）：如果兩個相同的、確定性的狀態從同一狀態開始，並且以相同的順序獲得相同的輸入，那麼這兩個狀態機將會生成相同的輸出，並且結束在相同的狀態.
  　　也就是說，如果我們能按順序將command作用於狀態機，它就可以產生相同的狀態和相同的輸出。

那麼，狀態機該如何實現？見下圖（來自raft協議）
　　
上圖中，每個RSM都有一個replicated log，儲存的是來自客戶端的commands。每個RSM中replicate log中commads的順序都是相同的，狀態機按順序處理replicate log中的command,並將處理的結果返回給客戶端。由於狀態機具有確定性，因此每個狀態機的輸出和狀態都是相同的。

Consensus Module模組的作用是：保證每個server上Log的一致性！ 如果不做任何保障，直接將commad暴力寫入，一旦伺服器當機或者出現什麼其他故障，就會導致這個Log丟失，並且無法恢復。而出現故障的可能性是很高的，這就導致系統不可用。

因此，raft就是Consensus Module的一個實現，是用來保障servers上副本一致性的一種演算法，它是一個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。

Consensus一致性

再瞭解raft協議之前，首先了解一下一致性這個概念。Consensus一致性是指多個伺服器在狀態達成一致，但是在一個分散式系統中，因為各種意外可能，有的伺服器可能會崩潰或變得不可靠，它就不能和其他伺服器達成一致狀態。這樣就需要一種Consensus協議，一致性協議是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。

Raft為了實現Consensus一致性這個目標，過程如同選舉一樣，參選者需要說服大多數選民(伺服器)投票給他，一旦選定後就跟隨其操作。在Raft中，任何時候一個伺服器可以扮演下面角色之一：

• Leader: 處理所有客戶端互動，日誌複製等，一般一次只有一個Leader.
• Follower: 類似選民，完全被動
• Candidate候選人: 類似Proposer律師，可以被選為一個新的領導人
  

通常情況下（無主備切換時），一個leader, 其他是follower。Follower處於被動的狀態，它不能發起任何請求，只能回應leader和candidate的請求。Leader處理客戶端的請求，如果客戶端請求發到了follower，follower負責將請求重定向到leader。candidate作用是：選主過程中用於選出新主。

Term

Raft將時間劃分為Term。Term可以是任意長度的時間段。Term有一個連續遞增的id。每個term以選主開始，選主過程中，若干candidate嘗試成為leader。選主過程成功之後進到normal operation的階段，leader開始提供服務。選主可能因為選票分裂而失敗，此時在當前term沒有leader，在下一個term繼續選主。
　　
從上圖可以看到，任期是遞增的，這就充當了邏輯時鐘的作用；另外，term 3展示了一種情況，就是說沒有選舉出leader就結束了，然後會發起新的選舉，後面會解釋這種split vote的情況。

選舉過程

…

參考

• https://www.cnblogs.com/xybaby/p/10124083.html

未完待續。