作者: Unmesh Joshi

譯者: java達人

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

問題

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

解決方案

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

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

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

確定集群中的服務(wù)器數(shù)量

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

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

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

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

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

例如,讀者可以參考Raft Thesis和Zookeeper原創(chuàng)論文中發(fā)布的實際吞吐量數(shù)據(jù)。

例子

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