Raft是當前分散式領域最重要的一致性演算法之一，今天我們就來好好研究研究這個演算法的論文, 還有對應網站, 動畫, 不想看英文的也有中文的翻譯，所以我這邊就不翻譯了，主要還是記錄一下論文重點和自己的心得。
Raft演算法作者的初衷是對標Paxos演算法（過去十年分散式一致性的事實標準），但是要比它更易理解，主要手段有：
- 分解，把整個一致性問題拆分為Leader選舉、日誌複製和安全機制這三大方面還有角色改變這個小方面。所以模組化是一個軟體系統可維護、理解和擴充套件的不二手段。
- 減少狀態空間的狀態，相比於Paxos，Raft減少了非確定性和伺服器之間可以處於不一致的方式。所以在複雜的問題上做減法，可以減少很多不必要的繁瑣的步驟。
Raft使用了更強的Leader，感覺這和我之前看的OceanBase是相似的，就是增強Leader（UpdateServer）或者說單點的作用，加重中心化（這也是社會的運作方式，沒有Leader就是大家一盤散沙，文明是達不到今天這個程度的），要做決策就先選擇一個Leader，然後讓他去協調所有的決議，會更加簡單快速，而Paxos就是P2P或者說弱Leader的方式。事實上，我們之所以使用分散式系統也是迫不得已，如果單臺機器能搞定還要這麼多系統幹嘛？所以我們也要看到單點系統的好處，那就是一致性很容易保證，所以在分散式系統中使用一個增強（能力和責任）的單點既利於一致性的保證也能獲得分散式的優勢。
Leader全權負責管理日誌複製，從而實現一致性，所以有了Leader這一機制，一致性問題就可以被分解為上述三大方面了，下面分別說明。
-
Raft 的 Leader 是有 Term 時間限制的，類似於租約機制，這個機制能完善單純的心跳(因為有的機器太忙可能發不出或沒法響應心跳)。 隨機的選舉超時時間可以使得 Leader 選舉很少有選票平分的時候，按
Term number最大和先來先服務原則可以使得每一個 Term 內最多有一個 Leader（如果沒有 Leader 就會超時進入下一個 Term 進行新的選舉）。Leader 保持身份並阻止其他節點成為 Leader 的方法是不停地向其他節點傳送心跳訊息（也包含需要複製的日誌）。 -
Leader 為客戶端服務，處理所有客戶端請求亦即所有的系統變更，並把日誌複製分發給其他節點（包含失敗重試），leader 處理日誌不一致的手段是強制follower 複製自己的日誌，所以 follower 中與 leader 衝突的日誌會被覆蓋，leader 不刪除自己的日誌（只附加原則）。
-
leader選舉和日誌複製都需要一些安全機制來保證每個狀態機都按照相同的順序來執行相同的指令： ①. 選舉限制，除了1中的條件，還要求 candidate 具有已經提交的所有日誌條目，所以 voter 會主動拒絕日誌沒有自己新（通過Term Number 和 日誌長度 兩個指標進行比較）的候選人的投票請求。 ②. 提交之前Term內的日誌條目時，Leader 會使用這個條目的原始Term Number，而不是使用當前的Term Number，這樣更容易辨別日誌，而且要提交之前Term（如 2 ）的日誌時必須同時提交當前Term（如 4）的日誌，保證得到複製日誌的 follower A 下次更有可能成為Leader而不是那些只有較舊日誌但是新於A得到的舊日誌（如 3 新於 2 ）的follower
如果 follower 或者 candidate 崩潰了，那麼後續傳送給他們的請求都會失敗。Raft 中處理這種失敗就是簡單的通過無限的重試，因為Raft的這種請求都是冪等的，所以這樣重試不會造成任何問題。比如，一個follower如果收到附加日誌請求但是他已經包含了這一日誌，那麼他就會直接忽略這個新的請求。
Leader 選舉是 Raft 中對時間要求最為關鍵的方面。只要系統滿足下面的時間要求：
廣播時間（broadcastTime） << 選舉超時時間（electionTimeout） << 平均故障間隔時間（MTBF）
Raft 就可以選舉並維持一個穩定的Leader。當Leader崩潰後，整個系統會大約相當於選舉超時的時間裡不可用，廣播時間和平均故障間隔時間是由系統決定的，但是選舉超時時間是我們自己選擇的， Raft的請求 要接收方將資訊持久到儲存中去，所以廣播時間大約是 0.5 毫秒到 20 毫秒，取決於儲存的技術。因此，選舉超時時間可能需要在 10 毫秒到 500 毫秒之間。大多數的伺服器的平均故障間隔時間都在幾個月甚至更長，很容易滿足時間的需求。
叢集狀態切換通過一個共同一致（新老配置的結合）的中間狀態轉換實現，這樣基於兩階段的做法可以使得叢集平滑地進行狀態遷移。
閱讀原文：Mageekchiu