老司機帶你用 Go 語言實現 Raft 分布式一致性協議

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

  隨著大型網站的各種高並發訪問、海量資料處理等情境越來越多，如何?網站的高可用、易伸縮、可擴充、安全等目標就顯得越來越重要。

  為瞭解決這樣一系列問題，大型網站的架構也在不斷髮展。提高大型網站的高可用架構，不得不提的就是分布式。任何一個分布式系統都無法同時滿足 Consistency（一致性），Availability（可用性），Partition tolerance（分區容錯性）這三個基本需求，最多隻能滿足其中兩項。 但是，一個分布式系統無論在 CAP 三者之間如何權衡，都無法徹底放棄一致性（Consistency），如果真的放棄一致性，那麼就說明這個系統中的資料根本不可信，資料也就沒有意義，那麼這個系統也就沒有任何價值可言。所以，無論如何，分布式系統的一致性問題都需要重點關注。

  Raft 適用於一個管理日誌一致性的協議，相比於 Paxos 協議 Raft 更易於理解和去實現它。

上車

  Raft 通過選舉一個領導人，然後給予他全部的管理複製日誌的責任來實現一致性。領導人從用戶端接收日誌條目，把日誌條目複製到其他伺服器上，並且當保證安全性的時候告訴其他的伺服器應用日誌條目到他們的狀態機器中。擁有一個領導人大大簡化了對複製日誌的管理。例如：領導人可以決定新的日誌條目需要放在日誌中的什麼位置而不需要和其他伺服器商議，並且資料都從領導人流向其他伺服器。一個領導人可以宕機，可以和其他伺服器失去串連，這時一個新的領導人會被選舉出來。

  Raft 把時間分割成任意長度的任期，任期用連續的整數標記。每一段任期從一次選舉開始，一個或者多個候選人嘗試成為領導者。如果一個候選人贏得選舉，然後他就在接下來的任期內充當領導人的職責。在某些情況下，一次選舉過程會造成選票的瓜分。在這種情況下，這一任期會以沒有領導人結束；一個新的任期（和一次新的選舉）會很快重新開始。Raft 保證了在一個給定的任期內，最多隻有一個領導者。

  要實現 Raft 協議，參見：

  Raft 協議將整個過程分為主要3個步驟：

1. 領導者：和其他一致性演算法相比，Raft 使用一種更強的領導能力形式。比如，日誌條目只從領導者發送給其他的伺服器。這種方式簡化了對複製日誌的管理並且使得 Raft 演算法更加易於理解。

2. 領導選舉：Raft 演算法使用一個隨機計時器來選舉領導者。這種方式只是在任何一致性演算法都必須實現的心跳機制上增加了一點機制。在解決衝突的時候會更加簡單快捷。

3. 關係調整：Raft 使用一種共同一致的方法來處理叢集成員變換的問題，在這種方法中，兩種不同的配置都要求的大多數機器會重疊。這就使得叢集在成員變換的時候依然可以繼續工作。

  後面將通過這3個主要過程進行展開。

發車（領導的選舉）

  Raft 使用一種心跳機制來觸發領導人選舉。當伺服器程式啟動時，他們都是跟隨者身份。如果一個跟隨者在一段時間裡沒有接收到任何訊息，也就是選舉逾時，然後他就會認為系統中沒有可用的領導者然後開始進行選舉以選出新的領導者。要開始一次選舉過程，跟隨者先要增加自己的當前任期號並且轉換到候選人狀態。然後他會並行的向叢集中的其他伺服器節點發送請求投票的 RPCs 來給自己投票。候選人的狀態維持直到發生以下任何一個條件發生的時候，(a) 他自己贏得了這次的選舉，(b) 其他的伺服器成為領導者，(c) 一段時間之後沒有任何一個獲勝的人。當一個候選人從整個叢集的大多數伺服器節點獲得了針對同一個任期號的選票，那麼他就贏得了這次選舉並成為領導人。每一個伺服器最多會對一個任期號投出一張選票，按照先來先服務的原則。

  Raft 使用投票的方式來阻止候選人贏得選舉除非這個候選人包含了所有已經提交的日誌條目。候選人為了贏得選舉必須聯絡叢集中的大部分節點，這意味著每一個已經提交的日誌條目肯定在這些伺服器節點中至少存在一個上面。如果候選人的日誌至少和大多數的伺服器節點一樣新，那麼他一定持有了所有已經提交的日誌條目。請求投票 RPC 實現了這樣的限制： RPC 中包含了候選人的日誌資訊，然後投票人會拒絕掉那些日誌沒有自己新的投票請求。

  Raft 通過比較兩份日誌中最後一條日誌條目的索引值和任期號定義誰的日誌比較新。如果兩份日誌最後的條目的任期號不同，那麼任期號大的日誌更加新。如果兩份日誌最後的條目任期號相同，那麼日誌比較長的那個就更加新。

到站（日誌複製）

  一旦一個領導人被選舉出來，他就開始為用戶端提供服務。用戶端的每一個請求都包含一條被複製狀態機器執行的指令。領導人把這條指令作為一條新的日誌條目附加到日誌中去，然後並行的發起附加條目 RPCs 給其他的伺服器，讓他們複製這條日誌條目。當這條日誌條目被安全的複製，領導人會應用這條日誌條目到它的狀態機器中然後把執行的結果返回給用戶端。如果跟隨者崩潰或者運行緩慢，再或者網路丟包，領導人會不斷的重複嘗試附加日誌條目 RPCs（儘管已經回複了用戶端）直到所有的跟隨者都最終儲存了所有的日誌條目。

  Raft 的日誌機制來維護一個不同伺服器的日誌之間的高層次的一致性。這麼做不僅簡化了系統的行為也使得更加可預計，同時他也是安全性保證的一個重要組件。Raft 維護著以下的特性，這些同時也組成了的日誌匹配特性：

1. 如果在不同的日誌中的兩個條目擁有相同的索引和任期號，那麼他們儲存了相同的指令。
2. 如果在不同的日誌中的兩個條目擁有相同的索引和任期號，那麼他們之前的所有日誌條目也全部相同。

  第一個特性來自這樣的一個事實，領導人最多在一個任期裡在指定的一個日誌索引位置建立一條日誌條目，同時日誌條目在日誌中的位置也從來不會改變。第二個特性由附加日誌 RPC 的一個簡單的一致性檢查所保證。在發送附加日誌 RPC 的時候，領導人會把新的日誌條目緊接著之前的條目的索引位置和任期號包含在裡面。如果跟隨者在它的日誌中找不到包含相同索引位置和任期號的條目，那麼他就會拒絕接收新的日誌條目。

  一致性檢查就像一個歸納步驟：一開始空的日誌狀態肯定是滿足日誌匹配特性的，然後一致性檢查保護了日誌匹配特性當日誌擴充的時候。因此，每當附加日誌 RPC 返回成功時，領導人就知道跟隨者的日誌一定是和自己相同的了。

下車

源於 MIT，然後用於自己學習，源碼注釋地址。