特別勧告：2つの軍隊の問題、Paxosプロセスに関する例を含む優れた記事！
パクソス
平易な英語で提示Paxosアルゴリズムは、非常に簡単です。
简单个屁
ねらい
分散システムでは、複数のコンピュータが問題に同意する必要があります（たとえば、共通のコマンドシーケンスを選択する必要があります）。いつでもダウンタイム、通信障害、遅延が発生する可能性がある条件で通信プロトコルを設計する必要があります（ただし、情報は途中で変更されません）。したがって、最終的に選択した結果はほとんどのマシンで受け入れられます。
注：提案と選択は人々に競争関係を与えるように見えますが、実際にはpaxosは協力関係を表しています。つまり、複数のマシンは、誰が合意を提案しようとも、より早く合意を得ようとします。
概念
- 選択：特定の値を含む提案がほとんどの承認者によって受け入れられると、この値が最終結果として決定され、値と対応する提案が選択されたと言います
- 特に、すべてが同じ値である限り、複数の提案を選択できます。
仮説
提案ごとに異なる数値が必要です。これの実装はハードウェアによって異なります。この記事では、それが真であると直接想定し、小さい数から大きい数までの自然数を使用します
プロトコル
契約ルール
最終結果を避けられないものにするためには、
- P1：アクセプターは彼が得た最初の提案を受け入れる必要があります
1つの結果のみを取得するために、
- P2：値がvの提案が選択された場合、それよりも大きい数値を持つすべての提案の値もvでなければなりません
このプロトコルを設計しているため、次の条件を指定するだけでP2を実装できます
- P2a：値がvのプロポーザルが選択されている場合、その値より大きい数値を持つ任意のアクセプターによって受け入れられたすべてのプロポーザルもvでなければなりません
アクセプターがダウンした場合、P1とP2aの両方に準拠させるために、実際にはより簡単に要求できます。
- P2b：値がvの提案が選択された場合、提案者が提案した数より大きい数の提案はすべてvの値も持つ必要があります
どのような状況下でP2bを達成できるかを確認でき、実際には次のようになることがわかりました
- P2c：公開された提案（n、v）の場合、過半数のアクセプターセットSが存在するか、このSのすべてのアクセプターにvがないか、Sのアクセプターが受け入れた最大の番号を持つ提案の値がvです。
P2cは、P2シリーズのすべての条件の実現を保証できます。これは、数学的誘導によって取得できます。
協定の実施
提案する
提案者の議題は2つのステップに分かれています。
- 新しい提案番号nを使用し、アクセプターセットの各メンバー（または少なくともそのほとんど）にリクエストを送信して、次のように返信するよう依頼します。
- n未満の数のプロポーザルが受け入れられなくなったことを確認します（作成されたが受け入れられなかったプロポーザルは、それとの競合を避けるために直接撮影されます）
- Acceptorが現在特定の提案を受け入れている場合は、この提案を返します（数と値を含む）
- 提案者がほとんどの承認者の応答を受け取った場合にのみ、提案を公開することが許可され（そうでない場合は、手順1に戻ります）、その内容は次のとおりです。
- 応答として受け入れられたすべてのアクセプターに現在提案がない場合、提案者は任意の値を使用して提案を行うことができます
- それ以外の場合は、応答するアクセプターによって受け入れられた提案の中で最大数の提案に対応する値を使用します
アクセプター
提案者のアジェンダに基づいて、アクセプターの行動規範をより正確に指定する必要があるため、P1条件を拡張する必要があります
- P1a：アクセプターできますnより大きいプロポーザル要求番号に応答しなかった場合に限り、n番のプロポーザルを受け入れます。
- 注：「できること」は元のテキストでは「できる」と表現されていますが、後で行う実行プロセスの説明によれば（提案がない限り受け入れます...）、より適切で便利である可能性があり、適切である必要があることがここで理解されています。理解
これで、このアルゴリズムは実際には完全ですが、より効率的な実行のために、以下の最適化を導入します
- 以下の状況では、アクセプターは準備リクエストに応答しません
- nを超える準備リクエストを受け取った（コストの節約に加えて、この最適化にはいくつかの追加の意味があります。それ以外の場合、提案者は受け取った提案の最大数を手元の数と比較する必要があります。または、受け入れ者が最初に準備要求応答を受け入れる必要があるかどうか）
- 番号nの提案が受け入れられました（おそらく提案者が繰り返し情報を送信したためです）
この最適化では、Acceptorは最新の受け入れ済み提案（つまり、受け入れた最大数の提案）と応答した最大数の準備要求の数のみを覚えておく必要があります。
完全なプロセス
準備フェーズ
- 提案者は提案番号nを使用して、コンテンツnの準備リクエストをすべての受け入れ者または少なくとも1人の過半数に送信します
- アクセプターはn番の準備リクエストを受け取ります。nが応答した準備リクエストの数より大きい場合、n未満の数の提案を受け入れないことを約束し、受け入れた最大の数の提案を返します。
受け入れフェーズ
- Proposerは、準備リクエストに対するAcceptorの応答のほとんどを受信すると（そうでない場合、提案を行いません）、番号nと値vのAcceptリクエストをこれらのレスポンダに送信します。応答に提案がある場合、vは最大数の提案の値に等しく、それ以外の場合、vは任意です。
- Acceptorは、プロポーザル番号がnであるAcceptリクエストを受信します。nより大きい数値のPrepareリクエストに応答していない場合、すぐに受け入れてAcceptedを返します。それ以外の場合は、Rejectedを返します。
提案者は、アルゴリズム要件を満たすことができる限り、複数の提案を生成できます。契約期間中いつでも提案を放棄することができます。
承認者がより大きい数の準備要求をすでに受け入れているために、他の準備または受け入れ要求を無視する場合、対応する提案者に提案を放棄するよう通知する必要があります。これは単なるパフォーマンスの最適化であり、正確さとは関係ありません。
学習者
学習者は選択した値を取得する必要があります。考慮できる戦略は次のとおりです
- 各承認者は、提案を受け取った後、この提案をすべての学習者に送信します
- この合計により、学習者は選択した値をできるだけ早く見つけることができますが、多くの冗長な操作があります。
- 著名な学習者を選択すると、すべての受け入れ者が提案を送信し、最後に選択した値を他の学習者に通知します
- 著名な学習者が誤動作する可能性があるため、これは信頼できない可能性があります
- 著名な学習者のグループを選択します。最終結果が決定したら、誰でも他のすべての学習者に通知できます
- 上記2つの長所と短所を打ち消す
実際、メッセージが失われる可能性があるため、値が選択されたことを学習者が知ることはできません。そのため、学習者は、受け入れ者が受け入れた提案を直接尋ねることができます。さらに、アクセプターが失敗すると、メジャーが提案を受け入れたかどうかが不明になる可能性があります。この場合、学習者は、新しい提案が受け入れられたときに選択された値が何であるかを知るだけです。したがって、値が選択されているかどうかを学習者が知りたい場合、および選択されている場合、選択された値を知りたい場合は、提案者に提案を送信させることができます（上記のアルゴリズムを使用）。
ライロック
2人の提案者が準備リクエストを送信し続けると、相手の承認リクエストが繰り返し無効になります。
プロセスの実行を確実にするために、唯一の提案送信者として、優れた提案者を選択する必要があります。