Dynamo のようなデータベース (Cassandra など) は、クォーラムによって一貫性を確保できます。つまり、同期的に書き込まれるレプリカの数 (W) と読み取るレプリカの数 (R) は、W+R>N となるように選択する必要があります。 N は複製係数です。一方、Zookeeper のような PAXOS ベースのシステムは、一貫したフォールト トレラント ストレージとしても使用されます。
これら2つのアプローチの違いは何ですか? PAXOS は、W+R>N スキーマによって提供されない保証を提供しますか?
Paxos の実装は簡単ではありません。また、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 に実装されたクォーラムの場合、Paxos はより強力な信頼性保証を提供するように見えます。
Paxos と W+R>N クォーラムは、わずかに異なる問題を解決しようとします。通常、Paxos はステート マシンを複製する方法として説明されますが、実際には分散ログに近いものです。ログに書き込まれた各項目はインデックスを取得し、最終的に異なるサーバーが同じログ項目とそのインデックスを保持します。(レプリケートされたステート マシンは、ステート マシンへの入力をログに書き込むことで実現できます。各サーバーは、インデックスに従って合意された入力でステート マシンを再生します)。Paxos の詳細については、私がここに書いたブログ投稿を参照してください。
W+R>N クォーラムは、複数のサーバー間で 1 つの値を共有するという問題を解決します。アカデミアでは「共有台帳」と呼ばれています。共有レジスタには、読み取りと書き込みの 2 つの操作があります。読み取りが前の書き込みの値を返すことが期待されます。
したがって、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 クォーラム スキームにはさまざまな実装があり、その多くはあまり一般的でない障害を想定しています。したがって、この 2 つの違いは、サポートされている可能性のある障害に関する前提にも依存します。
違いはありません。クォーラムの定義では、2 つのクォーラムの交差部分は空ではありません。単純過半数定足数は、定義ではなく例です。ランポート博士の後の論文 "Vertical Paxos" を見てください。そこで彼は定足数の他の可能な構成を示しました。
Multi-decree paxos プロトコル (別名 Multi-Paxos)。定常状態では、2 フェーズ コミットにすぎません。投票番号の変更は、リーダーが失敗した場合にのみ必要です。
Zookeeper のレプリケーション プロトコル (ZAB) と RAFT はすべて Paxos に基づいています。違いは、リーダーが失敗した後の障害検出と移行にあります。