問題タブ [consensus]

次の状況で、飼育係がクライアントの FIFO 注文を約束する方法を知りたいです。

クライアントはサーバーに 3 つの操作を送信しました。set a = 1、set b = 1、set ready = true です。

set a = 1 がリーダーによって処理され、この tcp 接続に何か問題があり、このクライアントが新しい tcp 接続をリーダーに再接続しますが、set b = 1 操作が途中である可能性はありますか? . 次に、クライアントは新しい tcp 接続を使用して set ready = true 操作を送信します。したがって、set a = 1 は操作され、set b = 1 は操作されず、set ready = true も操作されます。

問題は、zab がクライアントの FIFO 注文をどのように約束するかです。

zab は、リーダーから応答のないすべての操作を再送信できます。この状況では、クライアントがリーダーに再接続すると、オペレーション set b = 1, set ready = true が再送されます。

これは、Zab が FIFO の順序をプライミングするために使用する方法ですか?

皆さん、ありがとうございました

誰でも、「完全非同期契約プロトコル」のステップ 3 (以下を参照) を明確にしてください。

プロセス P: 初期値 xp。

• ステップ 0 : 設定しr := 1ます。
• ステップ 1(1, r, xp) :すべてのプロセスにメッセージを送信します。
• ステップ 2N - t :タイプのメッセージが受信されるまで待ちます(1, r, x)。複数のN/2メッセージが同じ値を持つ場合v、そのメッセージ(2, r, v, D)をすべてのプロセスに送信します。それ以外の場合は、メッセージ(2, r, ?)をすべてのプロセスに送信します。
• ステップ 3N - t :タイプのメッセージが(2, r)到着する まで待ちます。
  • (a) D メッセージが 1 つある場合は(2, r, v, D)、 を設定しxp := vます。
  • t(b) D メッセージより多い場合は、決定しvます。
  • (c) Else セットxp = 1または0確率 1/2 のそれぞれ。
• ステップ 4 : 設定r := r + 1してステップ 1 に進みます。

私はこのプロトコルを次のように理解しています。

最初のステップで、各ノードは他のすべてのノードにその状態を通知します。

2 番目のステップで、各ノードは、値を決定するのに十分な情報を「見た」かどうかを判断します。つまり、過半数を待ちます。多数派が同じ値を持っている場合、「多数派が考えているのを見た」のように、この情報をブロードキャストし始めますv。それ以外の場合は、決心しなかったというメッセージを送信します。

最後に、3 番目のステップで、複数のt「決定的な」メッセージがあるかどうかを確認します (tノードのメッセージが配信されない場合に備えて、少なくとも 1 つの「決定的な」メッセージがあります)。しかし、 D メッセージを1 つxp := vだけ受信した場合にのみ設定する理由がわかりません。2 つの D メッセージを受信すると 3c に分類されます。この場合、v にランダムな値を割り当てます。なぜですか?

3 番目のステップを次のように説明できないのはなぜですか。

• (a) D メッセージがゼロの場合、1/2 の確率で設定xp = 1または0それぞれ。
• t(b) D メッセージより多い場合は、決定しvます。
• (c) Else セットxp := v.

Xサーバーの動的ネットワーク（時間の経過とともに修正されない）があり、追加のみのデータベースにすべてのイベントの同一のコピーがあるとしましょう。今、私はこれら 10 台のサーバーのいずれかで新しいイベントの作成をサポートし、コンセンサスに達し、イベントを複製し、すべてがまったく同じイベント順序になるようにしたいと考えています。これは一般的な問題であり、このようなことを処理することになっているアルゴリズムがあることを理解しています. しかし、私はそれらを完全には把握しておらず、特にイベント ソーシングに関するコンセンサスに関していくつか質問があります。

サーバーは、コンセンサスに達したと思う値が実際に「正しい」値になることを完全に確信することはできないと思いますか? これは、新しいサーバーがいつでもネットワークに参加できるという事実に基づいており、バランスを崩して別の値を優先することができます。これは、かなり後で発生する可能性もあります。しかし、この場合、サーバーは新しい「正しい」値をどのように処理する必要がありますか? イベントソーシングでは、修正を行うために補正イベントを追加するのが普通ですが、これらの補正イベントをすべてのサーバーにも複製する必要はありませんか? すべてのサーバーにまったく同じイベントがあることを確認するということです。

補償イベントを追加するのではなく、既にコミットされたイベントを「ポッピング」するだけの場合、これらを複製する必要はないと思いますが、代わりに他の問題に遭遇します。(誤って) コミットされたイベントがイベント バスで送信され、他のサービスがそれらに反応できるようになった場合、混乱させずにイベント データベースからイベントをポップすることはできません。

それとも、短期間でコンセンサスに達した時点で、その値にコミットするほうがよいのでしょうか? そして、すべての新規/遅延サーバーを冷たい手で扱いますか? とにかく彼らに結果を受け入れさせますか？新しいサーバーが、最初のサーバーよりも大きい独自のネットワークに接続されていて、それらすべてが別の値について合意に達した場合はどうなるでしょうか?