分佈式系統的共識(consensus)算法比較

這是一篇比較分佈式系統中服務器之間得到狀態最終一致性也就是取得共識consensus幾個流行算法，包括Paxos、Egalitarian Paxos、Hydra、Fast Paxos、Ios、VRR(Viewstamped Replication Revisited)、 Multi-Paxos、Raft等。

什麼是共識consensus？當多個主機經過異步通信方式組成網絡集羣時，這種異步網絡默認是不可靠的，那麼在這些不可靠主機之間複製狀態須要採起一種機制，以保證每一個主機的狀態最終達成相同一致性狀態，取得共識。

爲何認爲異步網絡默認是不可靠的？這是根據FLP原理。Impossibility of Distributed Consensus with One Faulty Process一文提出：在一個異步系統中咱們不可能確切知道任何一臺主機是否死機了，由於咱們沒法分清楚主機或網絡的性能減慢與主機死機的區別，也就是說咱們沒法可靠地偵測到失敗錯誤。可是，咱們還必須確保安全可靠。

在實際中，咱們首先必須接受系統可能不可用，而後試圖減輕這種不可用，而不是徹底迴避去除，減輕的手段有定時器和補償。Paxos等算法所以而誕生。

Paxos算法是最初最簡單的分佈式共識算法，它是經過節點之間來回兩次實現狀態複製（兩段複製），可是Paxos這種來回兩次的協調過程（甚至更長）拖延了時間，增長了系統的延遲。

在實際過程當中，Paxos這種理想化的協議實際遭遇不少挑戰，也就是說，實際中有不少問題呼喚一種分佈式協調機制來處理下面這些問題：

1. 處理磁盤故障和損壞

2. 處理有限的存儲容量

3. 有效處理只讀請求

4. 動態成員資格和從新配置

5. 支持事務

6. 驗證明施的安全

這就須要一種領導人或協調人角色來具體處理這些問題，Paxos是一種無領導人Leaderless算法，而Raft算法是一種強領導力Leadership的算法。總之，之因此須要協調領導人是爲了確保主機之間狀態複製過程的可靠性。

一個強勢領導人Leadership可以在問題發生時在主機之間進行復雜的強協調，顯然Leaderless則是無領導人或協調人介入處理。可是強領導在保證可靠性的同時也會彙集單點風險，並且選舉領導人的過程也是費時費力的，所以，並非領導力越強越好。須要根據本身的業務領域特色在Leadership和Leaderless之間選擇合適本身的算法。

從Leadership到Leaderless以此從強到弱的排序是：

1. Strong Leadership強領導：Raft

2. Leader driven領導人驅動：VRR和 Mutil-Paxos

3. Leader with Delegation有表明團的領導人：Ios

前面三個重視單個領導人的算法MultiPaxos,Raft 和 VRR的問題是：吞吐量將受到單個節點的限制。而Ios容許一個領導人動態地安全地委託其職責給系統中其餘節點（表明團）。

4. Leader only when needed只有在須要時纔有領導人：Hydra和Fast Paxos

5. Leaderless無領導人：Egalitarian Paxos和普通的Paxos

上述算法中，最小延遲的算法是VRR，最易於理解的是Raft，而對於廣域網地區之間複製，衝突最少conflicts rare的是 Egalitarian Paxos; conflicts common是 Fast Paxos.

上述算法須要結合實際以及CAP理論與FLP綜合判斷選擇。

當前，日益普遍使用的微服務架構會很天然地橫向擴展到分佈式系統，雖然微服務自己是無態的，可是它會操做有態數據，這些有態數據要麼放在數據庫中，要麼放在緩存中，那麼緩存或數據庫進行橫向擴展組成分佈式系統時就須要使用上面這些算法，固然一些NoSQL數據庫內部已經實現了這些算法，那麼瞭解這些算法也能對咱們進行NoSQL選型有參考做用。