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

banq發表於2016-03-10
分散式演算法
這是一篇比較分散式系統中伺服器之間獲得狀態最終一致性也就是取得共識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綜合判斷選擇。

原文PPT

當前，日益廣泛使用的微服務架構會很自然地橫向擴充套件到分散式系統，雖然微服務本身是無態的，但是它會操作有態資料，這些有態資料要麼放在資料庫中，要麼放在快取中，那麼快取或資料庫進行橫向擴充套件組成分散式系統時就需要使用上面這些演算法，當然一些NoSQL資料庫內部已經實現了這些演算法，那麼瞭解這些演算法也能對我們進行NoSQL選型有參考作用。

[該貼被banq於2016-03-12 13:10修改過]

相關文章