閱讀筆記（二十四）Raft算法《in search of an understandable consensus algorithm》

一. 簡介

  paxos算法是Lamport大神提出的共識算法，在衆多分佈式系統中均有使用，在前文中有對Paxos算法的分析，以及谷歌運用該算法遇到的問題。但是paxos本身實現起來較爲複雜，因此業界出現了另一種更爲方便實現的共識算法:Raft。

  首先要推薦一個動畫網頁，該網頁將raft的七八成內容以動畫的形式展示了出來，還剩一些細節無法展現或者有所疏漏，但是可以大體上了解該算法的整個原理了。本文不再複述共識算法的背景、原理，也不復述Paxos或者Raft簡單的原理，而是重點分析Raft的一些重要的細節以及和Paxos的區別。

二. Raft的改變

  相對於Paxos，Raft主要做了如下改變：

1. 問題分解

  Raft爲了更容易的解決共識問題，將問題分解爲幾個子問題：

• 如何選舉leader
• 如何做日誌複製
• 如何保障安全性
• 會員(membership)改變問題

  除此之外，作者在開發Raft中體現了一個精美的哲學思想：自由的算法會帶來更復雜的實現問題，而嚴格的限制則相反，可以帶來更爲簡潔精美的算法實現。 究竟該採取何種方式其實無法直接論斷，而是要根據實際場景決定。這是每一個開發者都應該有的思想。

2. 更嚴格的leader選舉策略

  類似於Paxo，Raft的節點也有着三種狀態：Leader，Candidate和Follower。關係如下圖所示，簡單總結爲：

1. 沒有Leader的時候Follower在time out後進階爲Candidate，發出選舉申明
2. Candidate發起選舉，得到多數票則成爲Leader，發送選舉成功申明
3. 其他收到選舉成功消息的則進入Follower的狀態，直到Leader過期
   

  整個過程易於理解，而且和Paxos類似，在動圖網頁中可以很清晰地看到整個過程。下面着重說一下和Paxos的區別所在：

• Paxos中衆生平等，只要你擁有一個序列號，你就可以參與選舉，而你的序列號比較小被拒絕了，你可以很快的提出一個更大的序列號繼續參與選舉。

• Raft中定義了term，並且會根據term比較log的數量，當數量超過其他Follower的時候，才能被推選成功，結合下圖可以進行清楚地說明。

  圖中從左到右爲時間順序，五個節點中加粗的爲Leader，Leader將複製自身日誌給其他Follower更新。其中可能更新到一半就斷開了，發起了新的選舉。而進行到c的時候，如果是Paxos，則可能會進入d也可能會進入e。如果進入了d，則會出現3的日誌覆蓋了2和4term的日誌，從而導致了日誌的丟失。而在Raft中，則僅可能出現e的情況，因爲只有S1有可能選舉成功。這樣一來就可以極大的避免了更多更新的日誌丟失現象。

3. 日誌複製

  關於日誌複製其實上面已經大概說明了，這裏再詳細補充一下。如下圖所示爲Raft的日誌複製圖。其中第一個是leader，下面是follower。log index指的是日誌以索引的形式挨個存放，因此不會出現碎片問題。不同顏色表示不同的term，即不同的leader時代。可以看到，當leader選舉成功的時候，有些節點會缺漏了很多日誌，這裏leader會讓他們先通過複製儘快跟上 leader的狀態，在這個過程中不參與其他讀寫活動。這和chain replication也很相似。

4. 安全性

  這裏的安全性理解爲以下幾點

• 保障選舉的leader具有最權威的數據：因此Follower只接受term最新，log的index最多的Candidate
• 避免出現多個leader的情況：每個Follower僅僅有一次投票機會，投完票之後在該段期間內不允許重複投票。

5. membership change

  

總結

  本文着重分析了Paxos和Raft的不同，並探討了Raft一些獨到的做法和技術細節，更深入研究該算法還是請閱讀原文細細品味。