一. 簡介
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。關系如下圖所示，簡單總結為：
- 沒有Leader的時候Follower在time out後進階為Candidate，發出選舉申明
- Candidate發起選舉，得到多數票則成為Leader，發送選舉成功申明
- 其他收到選舉成功消息的則進入Follower的狀态，直到Leader過期
閱讀筆記（二十四）Raft算法《in search of an understandable consensus algorithm》
整個過程易于了解，而且和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一些獨到的做法和技術細節，更深入研究該算法還是請閱讀原文細細品味。