Paxosアルゴリズムは、メッセージパッシングに基づくコンセンサスアルゴリズムであり、高いフォールトトレランスを備えています。現在、分散整合性の問題を解決するための最も効果的なアルゴリズムの1つとして認識されています。コヒーレンスプロトコル--2PCと3PC、我々はそのような単一障害点として、欠点2PCと3PCの数を言及している、フォールトトレランスメカニズムが不十分である等、及びたPaxosアルゴリズムは、非同期システムのダウンタイム障害のない可能実行しますメッセージの損失、遅延、順序の乱れ、繰り返しを許容できる信頼性の高いメッセージ配信が必要です。多数決メカニズムを使用して2F + 1のフォールトトレランスを確保します。つまり、2F + 1ノードのシステムでは、最大でF個のノードで同時に障害が発生します。
Paxosのフローチャートは以下の通りで、具体的な処理手順は以下で詳しく説明します
Paxosは、システム内の役割を提案者、受け入れ者、学習者に分けます。
- 提案者：提案。プロポーザル情報には、プロポーザルID（Proposal ID）とProposed Value（Value）が含まれます。
- アクセプター：意思決定に参加し、提案者の提案に応答します。プロポーザルはプロポーザルを受け取った後で受け入れることができます。プロポーザルがほとんどのアクセプターによって受け入れられた場合、プロポーザルは承認されたと見なされます。
- 学習者：意思決定に参加せず、提案者/受け入れ者から最新の合意された提案（価値）を学びます。
1つ以上の提案プロセス（提案者）が提案（提案）を開始できます。Paxosアルゴリズムにより、すべての提案の中の特定の提案がすべてのプロセスで合意に達することができます。システムの多数派も提案に同意し（少数派は多数派に従う）、合意に達します。せいぜい特定の提案にのみ同意し、ほとんどの意思決定者（アクセプター）は値を受け入れます。値は受け入れられたと見なされます。つまり、意思決定者は値を読み取ることができます。これは、Paxosアルゴリズムが満たす必要のある制約条件です。
では、極端な例を最初に見てみましょう。提案プロセス（提案者）が提案（提案）を開始するときは常に、意思決定者（受け入れ者）のすべてまたはほとんどが同意しないので、どうすればよいですか？それは合意がないということですか？はい、この問題を回避するために、承認者は最初の提案を受け入れる必要があります（提案）、つまり、上の図のPaxosアルゴリズムのフローチャートの最初のステージでは、最初に判断されif(MaxN==null)，回应(ok, null, null)ます。nullを返すと、タスクをまだ承認/同意していない提案（Proposal）が参照されます。この値については、後で詳しく説明します。
したがって、提案（Proposal）を開始するProposer（Proposer）が1つだけあるとすると、プロセスは次のように非常に簡単です。
上記は、1つの提案プロセス（Proposer）のみが提案（Proposal）を開始し、各提案（Proposal）には提案番号Nがあることを前提としています。次に、複数の提案プロセス（Proposer）がある場合、提案（Proposal）を開始します。 、その後何が起こりますか？現時点では投票する必要があります。つまり、大多数が同じ提案を同時に認識できるようにする必要があります。プロセスは次のとおりです。
各提案者は提案を選択し、一連の意思決定者（承諾者）に要求を送信し、すべての意思決定者（承諾者）の少なくとも半分が提案（提案）、つまり意思決定者（承諾者）に同意することを要求します。次の点に同意します。
- プロポーザル（Proposal）IDが以下（注：ここは<=）です現在の要求の準備要求 、つまり、N未満の数の提案が受け入れられないことを保証することを提案者に約束します。これは、Paxosアルゴリズムのフローチャートの最初の段階、つまり準備段階を指します
- 意思決定者（承認者）が提案を受け入れた場合、提案者（提案者）がN未満の最大数の提案を受け入れたことに応答します。
- プロポーザルは受け付けられなくなりました（プロポーザル）IDが（注：ここは<）未満です現在のリクエストの提案リクエスト 、ここではPaxosアルゴリズムのフローチャートの第2ステージ、つまり合意ステージを指します。
1.以下のプロポーザルIDを受け入れなくなりました（注：ここでは<=）現在のリクエストのリクエストを準備します
まず、最初のポイントを見てみましょう。各プロポーザルIDには番号があります。番号が大きいプロポーザルは優先度が高くなります。異なるプロポーザによって提案されたプロポーザルの番号が異なることを確認するには、次のことを行う必要があります。番号を取得するための特別なメカニズム。番号には、ノード情報とノード自体によって提案されたタイミングが含まれている必要があります（たとえば、システム内の意思決定者（アクセプター）の番号nと提案者の番号mに基づくことができます）。たとえば、番号m提案者が提案した提案（Proposal）の数はm + i * nに変わります。iは提案の数です。つまり、i> = 0
2.意思決定者（アクセプター）がプロポーザルを受け入れた場合、プロポーザル（プロポーザー）が最大数N未満の数のプロポーザルを受け入れたことに応答します。
次に、2番目のポイントを見てみましょう。これは主に、提案者Aの提案の1つ（提案）が最初の段階（準備段階）で意思決定者（受容者）の過半数を通過したため、意思決定者は（承認者）は提案を受け入れ、合意に達し、提案者Aの提案（提案）を受け入れましたが、まだ確定していません。プロポーザーAは、プロポーザル（プロポーザル）を本当に実装する意思決定者（アクセプター）を見つけるために、第2段階に入っている必要があります。一般的な状況は次のとおりです。
ただし、現時点では、意思決定者（アクセプター）は意見を統一していますが、まだ確定していません。現時点では、新しい提案（Proposer）Bが提案され、新しい提案（Proposal）が提案されています。魅力的な（提案IDの方が大きい）場合、意思決定者（承認者）は反乱を起こし、提案者Bの提案に同意することができます。
しかし、彼らは提案者Bに、あなたの提案には同意したものの、あなたが遅れて到着したため、私たちの意思決定者（承認者）は意見を統一したと述べました。提案者Aの提案の具体的な内容をお知らせします。ここでは、提案者Aの提案の理由を提案者Bに開示します。詳細は以下のとおりです。
ここでは、提案者Bが提案者Aの提案の内容を開示した理由について説明します。ここでは、まず提案者Bの提案の内容について説明します。目的、ここでは提案者Aが第2フェーズでスムーズに進みました。これはほとんどの意思決定者（アクセプター）によって確認され、終了しました。
ただし、提案者Bがほとんどの意思決定者（承諾者）によって提案者Aの確認を受け取った場合、それはほとんどの意思決定者（承諾者）に対抗します。これは、提案者Aがほとんどの意思決定者（アクセプター）によって確認されていないため、最初のステージに戻り、前のプロセスを再度繰り返すことができます。
ここで、第2段階の提案者Aの失敗は第1段階に戻りますが、提案者Bがほとんどの意思決定者（承認者）の統合を取得すると、第2段階にスムーズに入ることができます。意思決定者（アクセプター）は以前に意見を統一しました。つまり、提案者Aの提案に同意します。提案者Aは第2段階で失敗しましたが、意思決定者（アクセプター）はこれに同意しました提案の内容。したがって、提案者Bが第2段階で提案の確認を開始するとき、提案者Aの提案の内容を送信して確認する必要があります。特定の値（プロポーザル）のプロポーザルが選択されている場合、数値が大きいすべてのプロポーザル（プロポーザル）の値もこの値である必要があります
これが必要な理由です特定の値（プロポーザル）のプロポーザルが選択されている場合、数値が大きいすべてのプロポーザル（プロポーザル）の値もこの値である必要がありますここでは、5人の意思決定者（アクセプター）がいるが、ネットワーク上の理由により2人が削除された場合、3人の意思決定者（アクセプター）のみが存在し、3人の意思決定者（アクセプター）が提案（プロポーザル）に同意すると仮定します。同意しました、これはネットワークが良好であること、オフラインである2人の意思決定者（アクセプター）が再接続されること、これは2人の意思決定者（アクセプター）が以前の提案に従って新しい提案（提案）を受け取った場合です承認者は最初の提案を受け入れる必要があります（提案） 原則として、新しい提案（Proposal）を受け入れる必要があり、システムの不整合につながります。上記の制限がある場合、同じ提案（Proposal）が導入されていなくても、提案（Proposal）の内容は同じですはい、その一貫性は保証されます。
3.プロポーザルIDが（プロポーザル）未満です（プロポーザル）IDが（注：ここは<）未満です現在のリクエストのリクエストを提案します
最後の点はどういう意味ですか？この点については、主にPaxosアルゴリズムのフローチャートの第2ステージである2番目のポイントに基づいて説明する必要があります。前述のように、合意ステージです。提案者Aの提案（Proposal）が最初です。ステージ-準備ステージはほとんどの意思決定者（アクセプター）の同意を通過し、次に、提案（プロポーザル）を実際に実装する意思決定者（アクセプター）を見つけるために第2ステージに入りました。
しかし、この時点で、プロポーザーAがプロポーザルを実際に決定する意思決定者（アクセプター）を探しているとき、最初の段階にある新しいプロポーザーBがいます。提案（Proposal）Bの提案（Proposal）IDの方が大きい場合、提案（Proposal）に同意する承認者を探します。決定者（Acceptor）は反抗的であり、提案者（提案者）Bの提案（提案）、上記2点目で詳しく紹介した提案内容（開示者）Aの提案（提案）を開示
ここで、提案者Aがすでに第2ステージで意思決定者（アクセプター）を見つけた場合は問題ありませんが、1ステップ遅れている場合は、反乱の後で戻ってそれを見つけてください。申し訳ありませんが、反抗的な名前です意思決定者（アクセプター）は考えを変えました。以前は廃止され、提案者Aは無視されました
上記はPaxosアルゴリズムのフローチャート全体の詳細な紹介です。要約すると、実際には2つの段階に分かれています
- 第一段階準備段階
- 提案者は提案番号Nを選択し、提案番号N（提案）を半分以上の意思決定者（承認者）に送信します。
- アクセプターがNの番号が付いたプロポーザル要求を受信し、Nが意思決定者（アクセプター）が応答したすべてのプロポーザル要求のID番号より大きい場合、それを受け入れます受け入れられた最大数の提案（ある場合）は応答として提案者にフィードバックされ、意思決定者（承認者）はN未満の数の提案を受け入れないことを約束します
- 第二段階-同意段階
- ProposerがNの番号が付いたそのプロポーザル（Proposal）に対する意思決定者（Acceptor）の半分以上から応答を受信した場合、[N、V]プロポーザルのAcceptリクエストを半分以上に送信しますアクセプター。
（注： Vは、受信した応答で最大の番号を持つ提案のコンテンツ値です。応答に提案が含まれていない場合、Vは提案者によって決定されます） - 意思決定者（Acceptor）が番号NのプロポーザルのAcceptリクエストを受信した場合、意思決定者（Acceptor）がNより大きい番号のPrepareリクエストに応答しない限り、プロポーザルを受け入れます。
- ProposerがNの番号が付いたそのプロポーザル（Proposal）に対する意思決定者（Acceptor）の半分以上から応答を受信した場合、[N、V]プロポーザルのAcceptリクエストを半分以上に送信しますアクセプター。
上記のPaxosアルゴリズムプロセスの理解を通じて、複数の提案者（提案者）が第1および第2ステージ、つまり提案者が第2ステージに入ることができるときはいつでも無限ループに陥る可能性があるという問題も発見しました当時、私にはほとんどの意思決定者（承認者）の最終的な同意を得る時間がありませんでした。ほとんどの意思決定者（承認者）は他の提案者（提案者）に反抗されましたが、最初の段階に戻るしかありませんでした。 。
上記の問題、つまり、Paxosアルゴリズムのアクティビティをどのように確認できるか、実際の環境では、提案を渡し、リーダーを選択します。後続のすべての提案は、Paxosアルゴリズムのアクティビティを確認するためにリーダーのみが行うことができます。
