2012-08-28 48 views
21

類似Dynamo的數據庫(例如Cassandra)可以通過仲裁強制執行一致性,也就是說,一些同步寫入的副本(W)和一些要讀取的副本(R)應該以W + R> N其中N是複製因子。另一方面,像Zookeeper這樣的基於PAXOS的系統也被用作一致的容錯存儲。Cassandra中Paxos和W + R> = N有什麼區別?

這兩種方法有什麼區別? PAXOS是否提供W + R> N模式不提供的保證?

+7

FWIW,Zookeeper不是基於Paxos的,它是一個兩階段提交協議(sans aborts),當主控制器關閉時使用單獨的自定義領導者選舉協議。當然,您可以將其視爲Vertical Paxos的實現,但最終所有正確的一致性算法都可以映射到Paxos。 –

回答

7

Paxos實現起來並不平凡,而且價格昂貴,許多使用它的系統也使用提示,或者我們只用於領導者選舉或其他事情。但是,它確實能夠在出現故障時保證一致性 - 當然這取決於其特定故障模型的限制。

我看到的第一個基於法定人數的系統假定某種領導或交易基礎結構可以確保足夠的一致性,從而可以相信法定人數機制起作用。這種基礎架構很可能是基於Paxos的。在描述諸如https://cloudant.com/blog/dynamo-and-couchdb-clusters/

來看,它會出現迪納摩是基礎上,保證其仲裁系統的一致性的基礎設施 - 所以它是非常聰明或偷工減料?根據http://muratbuffalo.blogspot.co.uk/2010/11/dynamo-amazons-highly-available-key.html,「Dynamo系統強調可用性以犧牲一致性,摘要爲」Dynamo在某些故障情況下犧牲一致性「。事實上,後來很明顯,即使在沒有故障的情況下,Dynamo也會犧牲一致性:Dynamo可能會變成在存在多個併發寫入請求時不一致,因爲副本可能因多個協調器而發生分歧。「 (結束報價)

因此,在Dynamo中實施法定人數的情況下,Paxos提供了更強的可靠性保證。

11

Paxos和W + R> N的法定人數試圖解決稍有不同的問題。 Paxos通常被描述爲一種複製狀態機的方式,但實際上它更像是一個分佈式日誌:寫入日誌的每個項目都會獲取一個索引,而不同的服務器最終會保存相同的日誌項目及其索引。 (複製狀態機可以通過向日志寫入狀態機的輸入來實現,並且每個服務器根據它們的索引在約定的輸入上重播狀態機)。您可以在我寫下here的博客文章中閱讀關於Paxos的更多信息。

W + R> N仲裁解決了在多個服務器之間共享單個值的問題。在學術界被稱爲「共享註冊」。共享寄存器有兩個操作:讀取和寫入,我們期望讀取返回先前寫入的值。

因此,Paxos和W + R> N的法定人數位於不同的域中,並且具有不同的屬性(例如,Paxos保存有序的項目列表)。但是,可以使用Paxos來實現共享寄存器,並且可以使用W + R> N仲裁來實現分佈式日誌(儘管效率非常低)。

說完所有上述情況,有時候W + R> N個法定人數並沒有以其「完全健壯」的方式實現,因爲它需要多次通信。因此,在需要低延遲的系統中,它們的W + R> N仲裁的實現可能會提供更弱的屬性(例如,可能存在衝突的值)。總而言之,從理論上講,Paxos和W + R> N可以實現相同的目標。實際上,這將是非常低效的,每一個稍微不同的東西都會更好。更實際的是,W + R> N並不總是完全實現,因此爲速度劃分了一些一致性屬性。

更新:Paxos支持非常普遍的故障模型:消息可以被丟棄,節點可以崩潰並重新啓動。 W + R> N仲裁方案具有不同的實現方式,其中許多方案假定的通用故障較少。因此,兩者之間的差異還取決於所支持的可能故障的假設。

14

是的,Paxos提供類似Dynamo的系統及其讀寫仲裁不提供的保證。不同之處在於如何處理故障以及寫入過程中會發生什麼。寫成功後,兩種系統的行爲都是相似的。數據將被保存並可供後續閱讀(直到被覆蓋或刪除)等等。

寫入期間和之後出現差異。在將某些東西寫入最終一致的系統時,直到您從W節點獲得成功的答案,那麼數據可能已寫入某些節點而不寫入其他節點,並且不能保證整個系統同意當前值。如果此時嘗試讀取數據,某些客戶端可能會返回新數據並返回一些舊數據。換句話說,系統並不是立即一致的。這是因爲這些系統中的節點寫入不是原子的。通常有機制來「修復」這樣的不一致性,並且「最終」系統將再次變得一致(即,讀取將再次總是返回相同的值,直到寫入新內容爲止)。這就是爲什麼他們經常被稱爲「最終一致」的原因。不一致可能(並且將會)出現,但它們總是會被最終處理和調和。

使用Paxos,可以使節點間的寫入成爲原子,因此節點之間的不一致可以避免。 Paxos算法可以保證無故障的節點在任何時候都不會不同意寫入的結果。無論寫入成功或無處。在任何時候都不會有任何不一致的讀法(如果它被正確實施並且當然所有的假設都成立)。然而,這是有代價的。主要地,當例如太多節點(或它們之間的通信)不工作時,系統可能需要延遲一些請求並且不可用。這是必要的,以確保沒有給出不一致的答覆。

總結:主要區別在於類似Dynamo的系統可能會在寫入期間或失敗後一段時間內返回不一致的結果(但最終會從中恢復),而基於Paxos的系統可以保證永遠不會有這樣的結果由於有時不可用而導致不一致,並延遲請求。

1

沒有區別。法定人數的定義表明任何兩個法定人數的交集不是空的。簡單多數法定人數不是一個定義。看看Dr. Lamport博士後來的論文「Vertical Paxos」,他在那裏給出了一些其他可能的法定人數配置。

多法令paxos協議(AKA Multi-Paxos),在穩定狀態下它只是兩階段提交。只有領導失敗時才需要更改投票號碼。

Zookeeper的複製協議(ZAB)和RAFT都基於Paxos。領導失敗後,差異在於故障檢測和轉換。

相關問題