作者: Unmesh Joshi

譯者: java達人

通過要求法定多數做出每個決策,以避免兩組服務器獨自決策。

問題

在分布式系統中,每當服務器執行操作時,都需要確保在發生崩潰的情況下,客戶端可以使用這些操作的結果。這可以通過將結果復制到集群中的其他服務器來實現。但是,這引出了一個問題:需要多少其他服務器確認復制,原服務器的更新才會被認可。如果原始服務器等待太多復制,則它將響應緩慢-活躍性減少。但是,如果沒有足夠的復制,則更新可能會丟失-失去安全性。在整體系統性能和系統連續性之間取得平衡是至關重要的。

解決方案

當集群中的大多數節點已確認更新時,集群同意已收到更新。我們稱這個數字為quorum法定數。因此,如果我們有五個節點的集群,則需要quorum 3。(對于n個節點的集群,quorum 為n / 2 +1。)quorum 表明可以容忍多少個故障-即集群的大小減去quorum。五個節點的集群可以容忍其中兩個故障。通常,如果我們要容忍“f”個故障,則需要一個2f +1的集群大小

考慮以下兩個需要quorum的示例:

? 更新服務器集群中的數據。High-Water Mark用于確保只有保證在大多數服務器上可用的數據才對客戶端可見。? 領導者選舉。在“領導者和追隨者”模式中,僅當領導者從大多數服務器中獲得選票時才被選擇。

確定集群中的服務器數量

僅當大多數服務器都已啟動并正在運行時,集群才能運行。在進行數據復制的系統中,需要考慮兩件事:

?寫操作的吞吐量。每次將數據寫入集群時,都需要將其復制到多個服務器。每個附加的服務器都會增加一些開銷,以完成此寫操作。數據寫入的等待時間與構成quorum的服務器數量成正比。正如我們將在下面看到的,將集群中的服務器數量加倍會使吞吐量降低到原始集群值的一半。

? 需要容忍的故障數量。允許的服務器故障數取決于集群的大小。但是,僅將一臺服務器添加到現有集群并不總是能提供更多的容錯能力:將一臺服務器添加到三臺服務器集群并不能提高容錯能力。

考慮到這兩個因素,大多數實際的基于quorum的系統的集群大小為3或5。一個由五臺服務器組成的集群可承受兩臺服務器故障,并且每秒可處理數千個請求的數據寫入吞吐量。

這是一個根據可容忍的故障數以及對吞吐量的大致影響來選擇服務器數量的示例。吞吐量列顯示近似的相對吞吐量,以突出顯示吞吐量如何隨服務器數量而降低。實際數量因系統而異。

例如,讀者可以參考Raft Thesis和Zookeeper原創論文中發布的實際吞吐量數據。

例子

? Zab,Raft,Paxos等所有共識實現都是基于quorum的。? 即使在未使用共識的系統中,quorum也可用于確保在出現故障或網絡分區時至少一臺服務器可以使用最新更新。例如,在像Cassandra這樣的數據庫中,可以將數據庫更新配置為僅在大多數服務器成功更新了記錄之后才返回成功。