領導選舉：raft 演算法使用乙個隨機計時器來選舉領導者。這種方式只是在任何一致性演算法都必須實現的心跳機制上增加了一點機制。在解決衝突的時候會更加簡單快捷。
成員關係調整：raft 使用一種共同一致的方法來處理集群成員變換的問題，在這種方法下，處於調整過程中的兩種不同的配置集群中大多數機器會有重疊，這就使得集群在成員變換的時候依然可以繼續工作。
可用性：集群中只要有大多數的機器可執行並且能夠相互通訊、和客戶端通訊，就可以保證可用。因此，乙個典型的包含 5 個節點的集群可以容忍兩個節點的失敗。伺服器被停止就認為是失敗。他們當有穩定的儲存的時候可以從狀態中恢復回來並重新加入集群。
不依賴時序來保證一致性：物理時鐘錯誤或者極端的訊息延遲在可能只有在最壞情況下才會導致可用性問題。
通常情況下，一條指令可以盡可能快的在集群中大多數節點響應一輪遠端過程呼叫時完成。小部分比較慢的節點不會影響系統整體的效能。
日誌複製：領導人必須從客戶端接收日誌然後複製到集群中的其他節點，並且強制要求其他節點的日誌保持和自己相同。
安全性：在 raft 中安全性的關鍵是在圖 3 中展示的狀態機安全：如果有任何的伺服器節點已經應用了乙個確定的日誌條目到它的狀態機中，那麼其他伺服器節點不能在同乙個日誌索引位置應用乙個不同的指令。章節 5.4 闡述了 raft 演算法是如何保證這個特性的；這個解決方案涉及到乙個額外的選舉機制（5.2 節）上的限制。
所有伺服器上持久存在的
currentterm
伺服器最後一次知道的任期號（初始化為 0，持續遞增）
votedfor
在當前獲得選票的候選人的 id
log日誌條目集；每乙個條目包含乙個使用者狀態機執行的指令，和收到時的任期號
所有伺服器上經常變的
commitindex
已知的最大的已經被提交的日誌條目的索引值
最後被應用到狀態機的日誌條目索引值（初始化為 0，持續遞增）
在領導人裡經常改變的 （選舉後重新初始化）
nextindex
對於每乙個伺服器，需要傳送給他的下乙個日誌條目的索引值（初始化為領***後索引值加一）
matchindex
對於每乙個伺服器，已經複製給他的日誌的最高索引值
解釋term
領導人的任期號
leaderid
領導人的 id，以便於跟隨者重定向請求
prevlogindex
新的日誌條目緊隨之前的索引值
prevlogterm
prevlogindex 條目的任期號
entries
準備儲存的日誌條目（表示心跳時為空；一次性傳送多個是為了提高效率）
leadercommit
領導人已經提交的日誌的索引值
解釋term
當前的任期號，用於領導人去更新自己
success
跟隨者包含了匹配上 prevlogindex 和 prevlogterm 的日誌時為真
如果日誌在 prevlogindex 位置處的日誌條目的任期號和 prevlogterm 不匹配，則返回 false （5.3 節）
如果已經存在的日誌條目和新的產生衝突（索引值相同但是任期號不同），刪除這一條和之後所有的 （5.3 節）
附加任何在已有的日誌中不存在的條目
如果leadercommit > commitindex，令 commitindex 等於 leadercommit 和 新日誌條目索引值中較小的乙個
解釋term
候選人的任期號
candidateid
請求選票的候選人的 id
lastlogindex
候選人的最後日誌條目的索引值
lastlogterm
候選人最後日誌條目的任期號
解釋term
當前任期號，以便於候選人去更新自己的任期號
votegranted
候選人贏得了此張選票時為真
如果 votedfor 為空或者就是 candidateid，並且候選人的日誌至少和自己一樣新，那麼就投票給他（5.2 節，5.4 節）
如果接收到的 rpc 請求或響應中，任期號t > currentterm，那麼就令 currentterm 等於 t，並切換狀態為跟隨者（5.1 節）
如果在超過選舉超時時間的情況之前都沒有收到領導人的心跳，或者是候選人請求投票的，就自己變成候選人
如果接收到大多數伺服器的選票，那麼就變成領導人
如果接收到來自新的領導人的附加日誌 rpc，轉變成跟隨者
如果選舉過程超時，再次發起一輪選舉
如果接收到來自客戶端的請求：附加條目到本地日誌中，在條目被應用到狀態機後響應客戶端（5.3 節）
如果對於乙個跟隨者，最後日誌條目的索引值大於等於 nextindex，那麼：傳送從 nextindex 開始的所有日誌條目：
如果存在乙個滿足n > commitindex的 n，並且大多數的matchindex[i] ≥ n成立，並且log[n].term == currentterm成立，那麼令 commitindex 等於這個 n （5.3 和 5.4 節）
解釋選舉安全特性
對於乙個給定的任期號，最多隻會有乙個領導人被選舉出來（5.2 節）
領導人只附加原則
領導人絕對不會刪除或者覆蓋自己的日誌，只會增加（5.3 節）
日誌匹配原則
如果兩個日誌在相同的索引位置的日誌條目的任期號相同，那麼我們就認為這個日誌從頭到這個索引位置之間全部完全相同（5.3 節）
領導人完全特性
如果某個日誌條目在某個任期號中已經被提交，那麼這個條目必然出現在更大任期號的所有領導人中（5.4 節）
狀態機安全特性
如果乙個領導人已經在給定的索引值位置的日誌條目應用到狀態機中，那麼其他任何的伺服器在這個索引位置不會提交乙個不同的日誌（5.4.3 節）
如果在不同的日誌中的兩個條目擁有相同的索引和任期號，那麼他們之前的所有日誌條目也全部相同。
領導人 t 複製這條日誌條目給集群中的大多數節點，同時，領導人u 從集群中的大多數節點贏得了選票。因此，至少有乙個節點（投票者、選民）同時接受了來自領導人t 的日誌條目，並且給領導人u 投票了，如圖 9。這個投票者是產生這個矛盾的關鍵。
這個投票者必須在給領導人 u 投票之前先接受了從領導人 t 發來的已經被提交的日誌條目；否則他就會拒絕來自領導人 t 的附加日誌請求（因為此時他的任期號會比 t 大）。
投票者在給領導人 u 投票時依然保有這條日誌條目，因為任何中間的領導人都包含該日誌條目（根據上述的假設），領導人從不會刪除條目，並且跟隨者只有和領導人衝突的時候才會刪除條目。
投票者把自己選票投給領導人 u 時，領導人 u 的日誌必須和投票者自己一樣新。這就導致了兩者矛盾之一。
首先，如果投票者和領導人 u 的最後一條日誌的任期號相同，那麼領導人 u 的日誌至少和投票者一樣長，所以領導人 u 的日誌一定包含所有投票者的日誌。這是另一處矛盾，因為投票者包含了那條已經被提交的日誌條目，但是在上述的假設裡，領導人 u 是不包含的。
除此之外，領導人 u 的最後一條日誌的任期號就必須比投票人大了。此外，他也比 t 大，因為投票人的最後一條日誌的任期號至少和 t 一樣大（他包含了來自任期 t 的已提交的日誌）。建立了領導人 u 最後一條日誌的之前領導人一定已經包含了那條被提交的日誌（根據上述假設，領導人 u 是第乙個不包含該日誌條目的領導人）。所以，根據日誌匹配特性，領導人 u 一定也包含那條被提交當然日誌，這裡產生矛盾。
這裡完成了矛盾。因此，所有比 t 大的領導人一定包含了所有來自 t 的已經被提交的日誌。
日誌匹配原則保證了未來的領導人也同時會包含被間接提交的條目，例如圖 8 (d) 中的索引 2。
新、舊配置的伺服器都可以成為領導人。
達成一致（針對選舉和提交）需要分別在兩種配置上獲得大多數的支援。
解釋term
領導人的任期號
leaderid
領導人的 id，以便於跟隨者重定向請求
lastincludedindex
快照中包含的最後日誌條目的索引值
lastincludedterm
快照中包含的最後日誌條目的任期號
offset
分塊在快照中的偏移量
data
原始資料
done
如果這是最後乙個分塊則為 true
解釋term
當前任期號，便於領導人更新自己
如果是第乙個分塊（offset 為 0）就建立乙個新的快照
在指定偏移量寫入資料
如果 done 是 false，則繼續等待更多的資料
儲存快照檔案，丟棄索引值小於快照的日誌
如果現存的日誌擁有相同的最後任期號和索引值，則後面的資料繼續保持
丟棄整個日誌
使用快照重置狀態機
緩和偏見採取的手段
可供檢視的材料
相同的講課質量
兩者使用同乙個講師。paxos 使用的是現在很多大學裡經常使用的。paxos 會長 14%。
相同的測驗難度
問題以難度分組，在兩個測驗里成對出現。
小測驗公平評分
使用紅字標題。隨機順序打分，兩個測驗交替進行。
紅字標題
關於 paxos 的更詳盡的描述，補充遺漏的細節並修改演算法，使得可以提供更加容易的實現基礎。
實現一致性演算法的系統，例如 chubby，zookeeper 和 spanner。對於 chubby 和 spanner 的演算法並沒有公開發表其技術細節，儘管他們都聲稱是基於 paxos 的。zookeeper 的演算法細節已經發表，但是和 paxos 著實有著很大的差別。
paxos 可以應用的效能優化。
oki 和 liskov 的 viewstamped replication（vr），一種和 paxos 差不多的替代演算法。原始的演算法描述和分布式傳輸協議耦合在了一起，但是核心的一致性演算法在最近的更新裡被分離了出來。vr 使用了一種基於領導人的方法，和 raft 有很多相似之處。
一致性演算法 Raft
乙個 raft 集群包含若干個伺服器節點 通常是 5 個，這允許整個系統容忍 2 個節點的失效，每個節點處於以下三種狀態之一 raft通過選出乙個leader來簡化日誌副本的管理，例如，日誌項 log entry 只允許從leader流向follower。基於leader的方法，raft演算法可以分...
Raft一致性協議
什麼是raft協議？我們應當知道，分布式儲存系統通常通過維護多個副本來進行容錯，提高系統的可用性。要實現此目標，就必須要解決分布式儲存系統的最核心問題 維護多個副本的一致性。raft協議就可以完成這個操作。為什麼用raft？除了raft，還有很多協議可以實現這個功能，比如說 兩階段提交協議，三階段提...
raft 一致性演算法
redis使用raft leader election進行master選舉。概念 乙個cluster中有多個node，最終狀態有乙個leader，多個follower。leader通過heartbeat週期性和follower通訊。node有三種狀態 leader，follower，candidat...