Paxos 和 Cassandra 中的 W+R>=N 有什么區別？

Question

類似 Dynamo 的數據庫（例如 Cassandra）可以通過仲裁來強制一致性，即應該以 W+R>N 的方式選擇多個同步寫入的副本 (W) 和多個要讀取的副本 (R)，其中N是復制因子。 另一方面，像 Zookeeper 這樣的基於 PAXOS 的系統也被用作一致的容錯存儲。

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

Answer 1

是的，Paxos提供類似Dynamo的系統及其讀寫仲裁不提供的保證。 不同之處在於如何處理故障以及在寫入期間發生的情況。 寫入成功后，兩種系統的行為都相似。 數據將被保存並隨后可供讀取（直到被覆蓋或刪除），依此類推。

寫入和失敗后會出現差異。 直到您在向最終一致的系統寫入內容時從W節點獲得成功答案，然后數據可能已寫入某些節點而不是其他節點，並且無法保證整個系統同意當前值。 如果此時嘗試讀回數據，則某些客戶端可能會返回新數據並返回一些舊數據。 換句話說，系統不是立即一致的。 這是因為這些系統中的節點之間的寫入不是原子的。 通常有機制來“治愈”這樣的不一致性，並且“最終”系統將再次變得一致（即讀取將再次始終返回相同的值，直到寫入新內容）。 這就是為什么它們通常被稱為“最終一致”的原因。 可以（並且將會）出現不一致的情況，但最終會對它們進行處理和協調。

使用Paxos，可以跨節點使寫入成為原子，因此可以避免節點之間的不一致。 Paxos算法可以保證非故障節點在任何時間點都不會對寫入結果產生不同意見。 無論是在任何地方還是在任何地方都能成功。 在任何時候都不會有任何不一致的讀取（如果它被正確實現並且當然所有假設都成立）。 然而，這需要付出代價。 主要是，當例如太多節點（或它們之間的通信）不起作用時，系統可能需要延遲一些請求並且不可用。 這是確保沒有給出不一致的答復所必需的。

總結一下：主要區別在於類似Dynamo的系統可以在寫入期間或失敗后返回不一致的結果一段時間（但最終會從中恢復），而基於Paxos的系統可以保證從來沒有任何這樣的不一致不可用和延遲請求。

Answer 2

Paxos和W + R> N法定人數試圖解決略有不同的問題。 Paxos通常被描述為復制狀態機的一種方式，但實際上它更像是一個分布式日志：寫入日志的每個項都獲得一個索引，不同的服務器最終擁有相同的日志項+它們的索引。 （可以通過將狀態機的輸入寫入日志來實現復制狀態機，並且每個服務器根據其索引在約定的輸入上重放狀態機）。 您可以在我在這里寫的博客文章中閱讀更多關於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仲裁方案具有不同的實現，其中許多假設不太普遍的失敗。 因此，兩者之間的差異還取決於對所支持的可能故障的假設。

Answer 3

Paxos實現起來非常重要，而且價格昂貴，許多使用它的系統也使用提示，或僅用於領導者選舉等等。 但是，它確實在出現故障時保證了一致性 - 當然要受其特定故障模型的限制。

我看到的第一個基於仲裁的系統假設某種領導者或事務基礎結構可確保足夠的一致性，您可以信任仲裁機制的工作原理。 這個基礎設施很可能是基於Paxos的。

看一下https://cloudant.com/blog/dynamo-and-couchdb-clusters/這樣的描述，似乎Dynamo 不是基於保證其仲裁系統一致性的基礎設施 - 所以它非常聰明或者偷工減料？ 根據http://muratbuffalo.blogspot.co.uk/2010/11/dynamo-amazons-highly-available-key.html，“Dynamo系統強調可用性，以犧牲一致性。摘要讀取”Dynamo犧牲一致性實際上，后來很明顯Dynamo甚至在沒有失敗的情況下犧牲了一致性：Dynamo可能在存在多個並發寫請求時變得不一致，因為副本可能由於多個協調器而分歧。 （結束語）

因此，似乎在Dynamo中實現的法定數量的情況下，Paxos提供了更強的可靠性保證。

Answer 4

沒有區別。 法定人數的定義表明任何兩個法定人數的交叉點都不是空的。 簡單多數仲裁是一個例子而不是定義。 看看Lamport博士后來的論文“Vertical Paxos”，他在那里給出了一些其他可能的法定人數配置。

多法令paxos協議（AKA Multi-Paxos），在穩定狀態下它只是兩階段提交。 只有在領導失敗時才需要改變選票號碼。

Zookeeper的復制協議（ZAB）和RAFT都基於Paxos。 在領導者失敗后，差異在於故障檢測和轉換。

Answer 5

正如其他答案中提到的，在 R+W > N 系統中，沒有事務，因此某些節點將具有較新的值和一些較舊的值。 以 n=3、r=2 和 w=2 的系統為例。 為清楚起見，我們假設這 3 個節點分別命名為 A、B 和 C。考慮這種情況：寫入正在進行，節點 A 已用 B 更新，而 C 仍在接收更新值的過程中。 從 A 和 B 讀取的客戶端將看到較新的值（使用版本向量或上次寫入獲勝解決），而從 B 和 C 讀取的客戶端將看到舊值。 這種類型的讀取不被認為是可線性化的。 使用適當的可線性化系統（例如 Paxos 或 Raft）不會出現此類問題。