Raft
html
Paxos偏向於理論、對如何應用到工程實踐說起較少。理解的難度加上現實的骨感，在生產環境中基於Paxos實現一個正確的分佈式系統很是難[1]：web
There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol.微信
Raft[2][3]在2013年提出，提出的時間雖然不長，但已經有不少系統基於Raft實現。相比Paxos，Raft的買點就是更利於理解、更易於實行。網絡
爲達到更容易理解和實行的目的，Raft將問題分解和具體化：Leader統一處理變動操做請求，一致性協議的做用具化爲保證節點間操做日誌副本(log replication)一致，以term做爲邏輯時鐘(logical clock)保證時序，節點運行相同狀態機(state machine)[4]獲得一致結果。Raft協議具體過程以下：app
Client發起請求，每一條請求包含操做指令分佈式
請求交由Leader處理，Leader將操做指令(entry)追加(append)至操做日誌，緊接着對Follower發起AppendEntries請求、嘗試讓操做日誌副本在Follower落地ide
若是Follower多數派(quorum)贊成AppendEntries請求，Leader進行commit操做、把指令交由狀態機處理大數據
狀態機處理完成後將結果返回給Clientui
指令經過log index(指令id)和term number保證時序，正常狀況下Leader、Follower狀態機按相同順序執行指令，得出相同結果、狀態一致。atom
宕機、網絡分化等狀況可引發Leader從新選舉(每次選舉產生新Leader的同時，產生新的term)、Leader/Follower間狀態不一致。Raft中Leader爲本身和全部Follower各維護一個nextIndex值，其表示Leader緊接下來要處理的指令id以及將要發給Follower的指令id，LnextIndex不等於FnextIndex時表明Leader操做日誌和Follower操做日誌存在不一致，這時將從Follower操做日誌中最初不一致的地方開始，由Leader操做日誌覆蓋Follower，直到LnextIndex、FnextIndex相等。
Paxos中Leader的存在是爲了提高決議效率，Leader的有無和數目並不影響決議一致性，Raft要求具有惟一Leader，並把一致性問題具體化爲保持日誌副本的一致性，以此實現相較Paxos而言更容易理解、更容易實現的目標。
Zab
Zab[5][6]的全稱是Zookeeper atomic broadcast protocol，是Zookeeper內部用到的一致性協議。相比Paxos，Zab最大的特色是保證強一致性(strong consistency，或叫線性一致性linearizable consistency)。
和Raft同樣，Zab要求惟一Leader參與決議，Zab能夠分解成discovery、sync、broadcast三個階段：
discovery: 選舉產生PL(prospective leader)，PL收集Follower epoch(cepoch)，根據Follower的反饋PL產生newepoch(每次選舉產生新Leader的同時產生新epoch，相似Raft的term)
sync: PL補齊相比Follower多數派缺失的狀態、以後各Follower再補齊相比PL缺失的狀態，PL和Follower完成狀態同步後PL變爲正式Leader(established leader)
broadcast: Leader處理Client的寫操做，並將狀態變動廣播至Follower，Follower多數派經過以後Leader發起將狀態變動落地(deliver/commit)
Leader和Follower之間經過心跳判別健康狀態，正常狀況下Zab處在broadcast階段，出現Leader宕機、網絡隔離等異常狀況時Zab從新回到discovery階段。
瞭解完Zab的基本原理，咱們再來看Zab怎樣保證強一致性，Zab經過約束事務前後順序達到強一致性，先廣播的事務先commit、FIFO，Zab稱之爲primary order(如下簡稱PO)。實現PO的核心是zxid。
Zab中每一個事務對應一個zxid，它由兩部分組成：<e, c>，e即Leader選舉時生成的epoch，c表示當次epoch內事務的編號、依次遞增。假設有兩個事務的zxid分別是z、z'，當知足 z.e < z'.e 或者 z.e = z'.e && z.c < z'.c 時，定義z先於z'發生(z < z')。
爲實現PO，Zab對Follower、Leader有如下約束：
有事務z和z'，若是Leader先廣播z，則Follower需保證先commit z對應的事務
有事務z和z'，z由Leader p廣播，z'由Leader q廣播，Leader p先於Leader q，則Follower需保證先commit z對應的事務
有事務z和z'，z由Leader p廣播，z'由Leader q廣播，Leader p先於Leader q，若是Follower已經commit z，則q需保證已commit z才能廣播z'
第一、2點保證事務FIFO，第3點保證Leader上具有全部已commit的事務。
相比Paxos，Zab約束了事務順序、適用於有強一致性需求的場景。
Paxos、Raft、Zab再比較
除Paxos、Raft和Zab外，Viewstamped Replication(簡稱VR)[7][8]也是討論比較多的一致性協議。這些協議包含不少共同的內容(Leader、quorum、state machine等)，於是咱們不由要問：Paxos、Raft、Zab和VR等分佈式一致性協議區別到底在哪，仍是根本就是一回事？[9]
Paxos、Raft、Zab和VR都是解決一致性問題的協議，Paxos協議原文傾向於理論，Raft、Zab、VR傾向於實踐，一致性保證程度等的不一樣也致使這些協議間存在差別。下圖幫助咱們理解這些協議的類似點和區別[10]：
相比Raft、Zab、VR，Paxos更純粹、更接近一致性問題本源，儘管Paxos傾向理論，但不表明Paxos不能應用於工程。基於Paxos的工程實踐，須考慮具體需求場景(如一致性要達到什麼程度)，再在Paxos原始語意上進行包裝。
小結
以上介紹分佈式一致性協議Raft、Zab的核心思想，分析Raft、Zab與Paxos的異同。實現分佈式系統時，先從具體需求和場景考慮，Raft、Zab、VR、Paxos等協議沒有絕對地好與很差，只是適不適合。
[1] Paxos made live - An engineering perspective, Tushar Chandra, Robert Griesemer and Joshua Redstone, 2007
[2] In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout, 2013
[3] In Search of an Understandable Consensus Algorithm (Extended Version), Diego Ongaro and John Ousterhout, 2013
[4] Implementing Fault-Tolerant Services Using the State Machine, Fred B. Schneider, 1990
[5] Zab:High-performance broadcast for primary-backup systems, FlavioP.Junqueira,BenjaminC.Reed,andMarcoSerafini, 2011
[6] ZooKeeper's atomic broadcast protocol: Theory and practice, Andr´e Medeiros, 2012
[7] Viewstamped Replication A New Primary Copy Method to Support Highly-Available Distributed Systems, Brian M.Oki and Barbar H.Liskov, 1988
[8] Viewstamped Replication Revisited, Barbara Liskov and James Cowling, Barbara Liskov and James Cowling ,2012
[9] Can’t we all just agree? The morning paper, 2015
[10] Vive La Difference: Paxos vs. Viewstamped Replication vs. Zab, Robbert van Renesse, Nicolas Schiper and Fred B. Schneider, 2014
有收穫就點個「在看」吧 ▼
本文分享自微信公衆號 - 老懞大數據（simon_bigdata）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。