10分鐘弄懂Raft演算法

分散式系統在極大提高可用性、容錯性的同時，帶來了一致性問題（CAP理論）。Raft演算法能夠解決分散式系統環境下的一致性問題。

我們熟悉的ETCD註冊中心就採用了這個演算法；你現在看的這篇微信公眾號文章，也是儲存在基於Raft演算法的高可用儲存伺服器中。

沒有耐心看文字，就直接拉到第四章。

一、Raft演算法是什麼？

過去，Paxos一直是分散式協議的標準，但是Paxos難於理解，更難以實現，Google的分散式鎖系統Chubby作為Paxos實現曾經遭遇到很多坑。後來史丹佛大學提出了Raft演算法。

Raft是用於管理複製日誌的一致性演算法。它的效果相當於(multi-)Paxos，跟Paxos一樣高效，但結構與Paxos不同。這使得Raft比Paxos更容易理解，也為構建實用系統提供了更好的基礎。

下圖是史丹佛大學的Diego Ongaro和John Ousterhout在《In Search of an Understandable Consensus Algorithm》一文（提出Raft演算法的論文）中，依據Raft學習難度的實驗資料繪製的。實驗物件是史丹佛大學和加州大學伯克利分校的高年級本科生和研究生。這些天才也覺得Paxos很難。所以對於大多數人看不懂Paxos演算法是很正常的，看不懂Raft原理也不奇怪。 

二、什麼是一致性（Consensus）

一致性是分散式系統容錯的基本問題。一致性涉及多個伺服器狀態（Values）達成一致。 一旦他們就狀態做出決定，該決定就是最終決定。 當大多數伺服器可用時，典型的一致性演算法會取得進展。例如，即使2臺伺服器發生故障，5臺伺服器的叢集也可以繼續執行。 如果更多伺服器失敗，它們將停止進展（但永遠不會返回錯誤的結果）。

三、Raft演算法

論文Raft演算法介紹的章節包括6個部分，瞭解個大概就行，然後拉到本文後邊，有個可操作的遊戲輔助理解這個演算法。

1、Raft基礎知識

Raft叢集包含多個伺服器，5個伺服器是比較典型的，允許系統容忍兩個故障。在任何給定時間，每個伺服器都處於以下三種狀態之一，領導者（Leader），追隨者（Follower）或候選人（Candidate）。 這幾個狀態見可以相互轉換。

Leader：處理所有客戶端互動，日誌複製等，一般一次只有一個Leader

Follower：類似選民，完全被動

Candidate：類似Proposer律師，可以被選為一個新的領導人 

2、選舉Leader

Raft使用心跳機制來觸發領導者選舉。 當伺服器啟動時，它們以Follower的身份開始。 只要伺服器從Leader或Candidate接收到有效的RPC請求，伺服器就會保持Follower狀態。 Leader向所有Follower傳送定期心跳（不帶日誌條目的AppendEntries RPC）以保持其許可權。 如果一個Follower在稱為選舉超時的一段時間內沒有接到任何通訊，該Follower認為沒有可行的領導者並開始選舉新的Leader。

3、日誌複製

一旦Leader當選，它就開始為客戶請求提供服務。每個客戶端請求包含由複製狀態機執行的命令。Leader將命令作為新條目附加到其日誌，然後並行地向每個其他伺服器發出AppendEntries RPC以複製條目。當條目被安全地複製時，Leader將條目應用於其狀態機並將該執行的結果返回給客戶端。如果Follower崩潰或執行緩慢，或者網路資料包丟失，Leader將無限期地重試AppendEntries RPC（即使它已經響應客戶端），直到所有Follower最終儲存所有日誌條目。（後邊遊戲中有個request命令選單，就是模仿客戶端請求的）

除了以上3點，文章還重點描述了安全、Follower和Candidate崩潰、時間和可用性三個方面。

四、視覺化的Raft演算法

github上有一個幫助大家理解演算法的頁面，地址是

建議用電腦瀏覽器開啟，如果在手機微信裡開啟，需要選擇“訪問原網頁”

我截了一個執行狀態的截圖，左側顯示五臺伺服器，右側顯示日誌。 

在伺服器圖示上點選滑鼠右鍵會出現操作選單。操作選單對應服務節點的狀態改變，其中request模擬客戶端請求伺服器叢集執行任務，會在右邊產生日誌。

多操作一會，一定能夠理解Raft演算法是怎麼執行的!

五、總結

Raft演算法具備強一致、高可靠、高可用等優點，具體體現在：

強一致性：雖然所有節點的資料並非實時一致，但Raft演算法保證Leader節點的資料最全，同時所有請求都由Leader處理，所以在客戶端角度看是強一致性的。

高可靠性：Raft演算法保證了Committed的日誌不會被修改，State Matchine只應用Committed的日誌，所以當客戶端收到請求成功即代表資料不再改變。Committed日誌在大多數節點上冗餘儲存，少於一半的磁碟故障資料不會丟失。

高可用性：從Raft演算法原理可以看出，選舉和日誌同步都只需要大多數的節點正常互聯即可，所以少量節點故障或網路異常不會影響系統的可用性。即使Leader故障，在選舉超時到期後，叢集自發選舉新Leader，無需人工干預，不可用時間極小。但Leader故障時存在重複資料問題，需要業務去重或冪等性保證。

高效能：與必須將資料寫到所有節點才能返回客戶端成功的演算法相比，Raft演算法只需要大多數節點成功即可，少量節點處理緩慢不會延緩整體系統執行。