分布式理論 六 Raft 演算法

我們之前講述了 paxos 一致性演算法，雖然樓主嘗試用最簡單的演算法來闡述，但仍然還是有點繞。樓主最初懷疑自己太笨，後來才直到，該演算法的晦澀難懂不是只有我乙個人這麼認為，而是國際公認！

所以 paxos 演算法在 1990 就發表出來，但卻得不到運用。真正的名聲大噪還是在蘭伯特使用 「更簡單」 的方式重寫了一篇**才開始。

這些和今天說的 raft 有什麼關係呢？

答：raft 也是乙個一致性演算法，和 paxos 目標相同。但他還有另乙個名字：易於理解的一致性演算法。

也就是說，他的目標就是成為乙個易於理解的一致性演算法。以替代 paxos 的晦澀難懂。

那我們就開始講講 raft 演算法吧！

首先說什麼是 raft 演算法：raft 是一種為了管理複製日誌的一致性演算法。

什麼是一致性呢？

raft 的**這麼說的：一致性演算法允許一組機器像乙個整體一樣工作，即使其中一些機器出現故障也能夠繼續工作下去。

這裡的一致性針對分布式系統。

什麼是管理日誌呢？

一致性演算法是從複製狀態機的背景下提出的，複製狀態機通常都是基於複製日誌實現的，這個日誌可以理解為乙個比喻，相當於乙個指令。

關於狀態機的描述：

多個節點上，從相同的初始狀態開始，執行相同的一串命令，產生相同的最終狀態。實際上，與其說是一致，其實可以泛化為分布式的兩個節點狀態存在某種約束。

複製狀態機通常都是基於複製日誌實現的，保證複製日誌相同就是一致性演算法的工作了。

典型應用就是乙個獨立的的複製狀態機去管理領導選舉和儲存配置資訊並且在領導人宕機的情況下也要存活下來。比如 chubby 和 zookeeper。

從樓主閱讀**的過程中來看，raft 相較於 paxos 確實更易於理解。為了提公升可理解性，raft 將一致性演算法分解成了幾個關鍵模組，例如領導人選舉、日誌複製和安全性。

raft 通過選舉乙個高貴的領導人，然後給予他全部的管理複製日誌的責任來實現一致性。

而每個 server 都可能會在 3 個身份之間切換：

而影響他們身份變化的則是選舉。

當所有伺服器初始化的時候，都是跟隨者，這個時候需要乙個領導者，所有人都變成候選者，直到有人成功當選領導者。

角色輪換如下圖：

而領導者也有宕機的時候，宕機後引發新的選舉，所以，整個集群在選舉和正常執行之間切換，具體如下圖：

從上圖可以看出，選舉和正常執行之間切換，但請注意， 上圖中的 term 3 有乙個地方，後面沒有跟著正常執行階段，為什麼呢?

答：當一次選舉失敗（比如正巧每個人都投了自己），就執行一次加時賽，每個 server 會在乙個隨機的時間裡重新投票，這樣就能保證不衝突了。所以，當 term 3 選舉失敗，等了幾十毫秒，執行 term 4 選舉，並成功選舉出領導人。

接著，領導者週期性的向所有跟隨者傳送心跳包來維持自己的權威。如果乙個跟隨者在一段時間裡沒有接收到任何訊息，也就是選舉超時，那麼他就會認為系統中沒有可用的領導者,並且發起選舉以選出新的領導者。

要開始一次選舉過程，跟隨者先要增加自己的當前任期號並且轉換到候選人狀態。然後請求其他伺服器為自己投票。那麼會產生 3 種結果：

a. 自己成功當選

b. 其他的伺服器成為領導者

c. 僵住，沒有任何乙個人成為領導者

注意：每乙個 server 最多在乙個任期內投出一張選票（有任期號約束），先到先得。

要求最多只能有乙個人贏得選票。

一旦成功，立即成為領導人，然後廣播所有伺服器停止投票阻止新得領導產生。

僵住怎麼辦？ raft 通過使用隨機選舉超時時間（例如 150 - 300 毫秒）的方法將伺服器打散投票。每個候選人在僵住的時候會隨機從乙個時間開始重新選舉。

以上，就是 raft 所有關於領導選舉的策略。

一旦乙個領導人被選舉出來，他就開始為客戶端提供服務。

客戶端傳送日誌給領導者，隨後領導者將日誌複製到其他的伺服器。如果跟隨者故障，領導者將會嘗試重試。直到所有的跟隨者都成功儲存了所有日誌。

下圖表示了當乙個客戶端傳送乙個日誌給領導者，隨後領導者複製給跟隨者的整個過程。

4 個步驟：

客戶端提交

複製資料到所有跟隨者

跟隨者回覆確認收到

領導者回覆客戶端和所有跟隨者確認提交。

可以看到，直到第四步驟，整個事務才會達成。中間任何乙個步驟發生故障，都不會影響日誌一致性。

raft 演算法如同他的**名字一樣：尋找一種易於理解的一致性演算法，這裡的易於理解是相對於 paxos 的，的確，paxos 實在過於複雜了。

而如何實現易於理解？

答：raft 將一致性演算法分成了2部分：領導選舉，日誌複製。

領導選舉基於乙個隨機的時間來保證不會衝突（如果衝突的話）。

而日誌複製則類似於 2pc。

通常 5 個節點，只要不超過 2 個節點死亡都不會影響系統的執行。保證了系統的可用性，通過領導者的日誌複製，實現了系統的一致性。

似乎 cap 定理已經不起作用了，當然這又是乙個重大的話題。

最後，以 raft **的結尾結束本位：

演算法的設計通常會把正確性，效率或者簡潔作為主要的目標。儘管這些都是很有意義的目標，但是我們相信，可理解性也是一樣的重要。在開發者把演算法應用到實際的系統中之前，這些目標沒有乙個會被實現，這些都會必然的偏離發表時的形式。除非開發人員對這個演算法有著很深的理解並且有著直觀的感覺，否則將會對他們而言很難在實現的時候保持原有期望的特性。

raft 英文原文

raft 為什麼是更易理解的分布式一致性演算法

分布式 Raft演算法

raft也是分布式一致性協議，主要是用來競選主節點。有三種節點 follower，candidate和leader。leader會週期性的傳送心跳給follower。每個follower都設定了乙個隨機的競選超時時間，一般為150ms 300ms，如果在這個時間內沒有收到leader的心跳包，就會變...

分布式系統 Raft演算法

什麼是拜占庭將軍問題？在很久很久以前，拜占庭是東羅馬帝國的首都。那個時候羅馬帝國國土遼闊，為了防禦目的，因此每個軍隊都分隔很遠，將軍與將軍之間只能靠信使傳遞訊息。在打仗的時候，拜占庭軍隊內所有將軍必需達成一致的共識，才能更好地贏得勝利。但是，在軍隊內有可能存有叛徒，擾亂將軍們的決定。這時候，在已知有...

分布式系統的Raft演算法

過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...