分散システムの一貫性のための3PCプロトコルについての簡単な説明

この記事はWeChatの公開アカウント「Backend Technology Compass」から転載したものです。この記事を転載する場合は、Backend Technology Compass の公開アカウントにお問い合わせください。

1. 前に書く

この号の分散システム一貫性特集では、3PC プロトコルについて記述する予定です。先週は忙しくて更新する時間がなかったので、古い記事を修正して再投稿しました。読者の皆様にはご容赦いただければ幸いです。これから Paxos プロトコル、Raft プロトコルなど、あと 3 つのフェーズが続きますので、まずはウォーミングアップをしましょう。ご注意：この記事は退屈なものではありません。描画ツールを変更しました。建築を専攻したIT犬の私にとって、絵を描くことはただただ幸せなことなので、ぜひ読んでみてください！

[[328175]]

写真（インターネット） |オリオン星雲

2. 3PCの出現

以前の記事では、コーディネータの単一ポイント、参加者のブロッキング タイムアウト、ネットワーク パーティショニング、フォールト トレランスなどの 2PC プロトコルの問題について説明しました。これらは、ある程度は最適化および調整することができ、致命的な問題ではありません。 2PC プロトコルの異常な状況を分解しましたが、これは m*n の組み合わせ問題です。私たちは主な矛盾を分析するために最善を尽くし、コーディネータと指示を受信する唯一の参加者の両方が回復不可能なダウンタイムを経験すると、後で新しいコーディネータが選出されたとしてもデータの不整合が発生する可能性があることを発見しました。 3PC の出現はさまざまな要因によって引き起こされる可能性があります。しかし、3PC が 2PC に存在する問題を修正し、最適化することは基本的に確実ですが、これは 3PC が新しい問題を導入しないことを意味するものではありません。この記事では、3PC プロトコル プロセスの次の 2 つの主要な内容について説明します。

3. 3PCプロトコルの基本プロセス

3PC プロトコル (Three-Phase-Commit) は、3 フェーズ コミット プロトコルとも呼ばれます。 2PC プロトコルと比較すると、もう 1 つのフェーズが追加されているため、一般的に 3PC プロトコルは 2PC プロトコルの改良版と見なされます。 3PC プロトコルは、2PC プロトコルの準備フェーズを 2 つのフェーズに分割し、次の 3 つのフェーズを形成します。

コーディネータと参加者の待機タイムアウト状況については個別に説明します。まずは通常の状況の基本的なプロセスを見てみましょう。そうしないと混乱しやすくなります。

3.1 CanCommitフェーズ

2PC 準備フェーズでは、コーディネータが参加者に指示を送信した後、参加者が実行条件を満たしている場合はロックを取得してアクションを実行しますが、実際には送信されません。参加者は成功まであと一歩のところにいるとみなされ、コーディネーターの合図を待つ必要があると考えられます。コミットシグナルであれば問題ありません。ロールバック信号の場合、ローカルでアクションを実行した一部の参加者にとっては無駄になります。したがって、この観点からすると、2PC は少し過激です。しかし、そうする理由はあります。複雑なネットワーク環境では、対話が 1 回増えるごとにパフォーマンスが低下します。 3PCの方が合理的です。コーディネーターはまず参加者に問い合わせ信号を送信し、時間があるかどうかを尋ねます。次に、コーディネーターは比較的軽量なフィードバックの収集を開始します。この段階では、参加者は実際にロックを取得してリソースを占有するのではなく、自身のトランザクション実行のステータスをチェックして、トランザクションを実行する条件を満たしているかどうかを確認し、問い合わせに応答するだけです。

クエリに対する参加者の応答に基づいて、CanCommit フェーズ中に次の 2 つの状況が発生する可能性があります。

A. 参加者全員が準備完了

図: 問い合わせ段階の参加者全員が取引を実行する資格がある

B. 参加者がOKでないシナリオがある

図: 調査段階における不適格な参加者

3.2 事前コミットフェーズ

第 2 段階の具体的なアクションは第 1 段階の結果によって異なるため、次の 2 つのケースに分けられます。

• CanCommitステージは満場一致で通過

最初のフェーズでは、参加者全員が準備できているので、コーディネーターが参加者にローカル実行指示を送信します。この部分は 2PC の最初のフェーズと非常によく似ています。参加者は指示を受けた後、ローカルトランザクションを実行し、ログを記録し、処理結果をコーディネータにフィードバックして意思決定を行います。参加者はプロセスで成功することも失敗することもあります。 2つの状況があります:

図: PreCommitフェーズの参加者全員が成功を報告

図: PreCommit フェーズの参加者間の失敗例

CanCommitフェーズでの意見の不一致

最初のフェーズでは、参加者の誰かが準備ができていない場合、コーディネーターはすべての参加者に信号を送信し、トランザクションがキャンセルされ、作業を続行できることを通知します。参加者は本質的には何もしていないので、損失はそれほど大きくありません。

3.3 DoCommitフェーズ

これは 3PC の第 3 フェーズであり、2PC の第 2 フェーズに似ています。 DoCommit によって実行される特定のアクションは、第 2 フェーズの PreCommit の結果にも依存するため、次の 2 つのケースに分けられます。

• PreCommitステージは満場一致で通過しました

PreCommit の後、すべての参加者はローカル トランザクションの実行を完了しましたが、コミットしておらず、全員がコーディネータに ACK で応答しています。この時点で、コーディネーターはすべての準備が整ったと判断し、DoCommit フェーズで、コーディネーターは参加者にコミット コマンドを送信します。それを受け取った後、参加者はローカルコミットの実行を開始し、結果をフィードバックして、最終的にトランザクションを完了します。いいね！

• 事前コミット段階での意見の不一致

第 2 フェーズの PreCommit で参加者からフィードバックを受け取った後、コーディネーターは一部の参加者がトランザクションを実行できないことを発見します。この時点で、他の参加者にローカルでロールバックし、リソースを解放し、トランザクションをキャンセルするように指示することを決定します。

IV. 3PCにおけるタイムアウト戦略

先ほど、3PC は 2PC における参加者のブロッキング タイムアウトの問題を解決するためのものであると述べました。 2PC では、参加者はより熱狂的になり、コーディネーターがシグナルを出さない場合、参加者は長時間ブロックされ、リソースを解放しなくなります。こうすると、他の人は他のことに対処できなくなり、それは確かに良くありません。 2PC はまだコーディネータに依存しすぎているようです。 3PC は、ネットワーク タイムアウトは頻繁に発生すると考えています。参加者が高確率状態で何らかの行動をとる場合、それは許可され、外部の軍事命令に左右されることはありません。 3PC タイムアウト処理は、PreCommit ステージと DoCommit ステージで発生する可能性があります。次の図を見てみましょう。

参加者がPreCommitを待機中にタイムアウトしました

コーディネーターと参加者の間で大きなネットワーク遅延が発生したり、コーディネーターに障害が発生したり、ネットワーク パーティションが発生したりする可能性があります。参加者は愚かに待つつもりはない。設定された時間が過ぎると、参加者は以前のタスクを続行します。取り残されたように感じられ、やるべきことしかできないからです。これも正しい決断です。

参加者がDoCommitを待機中にタイムアウトしました

CanCommit と PreCommit の後、参加者は全員が一致しており、すべてが順調であると考えます。参加者が設定された時間内にコーディネータから DoCommit 命令を受信しなかった場合、参加者はビッグブラザーがおそらくコミットを望んでいると推測し、待つことは解決策ではないため、トランザクションを完了するためにローカルでコミットを実行します。ロールバックは他のすべてのロールバックとは異なる場合があります。この決定に基づいて、参加者はトランザクションをコミットすることを選択します。

コーディネーターはフィードバックを待つ間にタイムアウトしました

3PC コーディネーターの待機タイムアウト処理は、基本的に 2PC の場合と同じです。どの段階でタイムアウトが発生した場合でも、条件が満たされていないとみなされ、中止またはロールバック操作が実行されます。これは非常に理解しやすいです。

3PC プロトコルの参加者は、もはやコーディネータのコマンド信号に過度に依存せず、独自の相対的な独立性を持ち、現在のステータスに基づいて独自の決定を下すことができることがわかります。 2PC でのブロックと待機によって生じるリソースの浪費を避けることは確かに良い最適化ですが、この最適化が完全に正しいことを完全に保証することはできません。つまり、3PC は 2PC のバグを解決しますが、3PC が新しいバグを導入しないことを意味するわけではありません。

5. 3PCプロトコルの分析

先ほど、3PC プロトコルの重要な役割は 2PC プロトコルを改善し、最適化することであると述べました。上記のプロセス分析から、確かにいくつかの最適化が行われたことがわかりますが、新たな問題は依然として避けられません。

5.1 3PCデータ不整合問題

2PC プロトコルでは、特定のシナリオでデータの不整合の問題が発生します。 3PC にはこの問題がありますか?答えは「はい」です。根本的な原因は、新しく追加された参加者のタイムアウト メカニズムにあります。たとえば、ネットワークの問題により、参加者 A は設定された時間内にコーディネーターからの信号を受信しません。このとき、参加者 A は前回の状態に基づいてコミット操作を実行し、トランザクションをコミットします。この状況は実際に発生し、実際のコーディネーター信号がコミットかロールバックかに応じて異なる結果が表示されます。

コーディネーターがコミットコマンドを送信した場合、参加者Aの独立した決定の結果と一致するため、問題はありません。コーディネータが DoCommit フェーズ中にロールバック命令を送信すると、タイムアウトした参加者 A は、ローカル トランザクション コミットを実行しているため、ロールバックを実行する命令を受信した他の参加者と矛盾したデータを持つことになります。

5.2 決定状態の整合

2PC プロトコルの初期段階では、意思決定者だけが意思決定結果を知っており、意思決定者が意思決定ソリューションを送信した後にのみ参加者がそれを知るため、意思決定結果が失われる可能性があることがわかっています。コーディネーターが失敗した場合、新しいコーディネーターはすべての参加者に相談して、すべての参加者の状況に基づいて決定ステータスを決定できますが、真実が少数の人々の手にある場合はどうなるでしょうか?

極端なケース:

参加者が 10 人いて、そのうち 9 人が正常で、1 人の状態が不明 (A と呼ぶことにします) であるとします。参加者 10 人全員がコーディネーターにフィードバックを送信します。 A が Not Ready 信号を送信すると、他の 9 つは Ready 信号を送信します。コーディネータは結果を要約し、実行条件が満たされていないと判断し、すべての参加者にロールバックの送信を開始します。信号を最初に受信したマシンは A です。コーディネーターがクラッシュし、信号を受信した後、A もクラッシュします。新しいコーディネーターが他の 9 人に尋ねると、全員が「はい」と答えます。新しいコーディネーターはすべての条件が満たされていると判断し、コミット信号を送信しますが、これにより不整合が発生します。

脳を開く:

このプロセスは、清朝の宮廷劇における皇帝による皇太子の任命と非常によく似ています。皇帝はその結果を宮廷の銘板に掲げた。勅令が消滅し、皇帝が亡くなった場合、結果は不明となる。シンクタンクは、利己的な動機なしにすべての候補者の状況を検討し、矛盾が生じる可能性のある決定を下す必要がある。

意思決定の透明性:

3PC では、1 台のマシンだけが命令を受信して​​ハングアップする状況が依然として存在しますが、それが前段階で発生した場合、キャンセルされ、参加者がローカルで実行しないため、全体の結果には影響しません。

さて、3PCの考え方は、主要なアクションを行う際の決定結果を透明かつ統一化することで、影響が非常に小さくなるため、PreCommit段階のステータスが明確になります。

すべての参加者が決定結果を知ることができるように、決定結果を透明化する必要があります。 3PC の PreCommit フェーズでは、結果が調整されます。 1 台のマシンが稼働している限り、トランザクション全体のステータスは確実です。結局のところ、参加者全員が電話を切る可能性は非常に低いのです。

6. まとめ

3PC プロトコルは、2PC プロトコルの最適化と改良です。 2PC の準備フェーズを CanCommit と PreCommit の 2 つに分割することで、プロセス全体の次のフェーズのフローは前のフェーズの結果に依存します。フロー図は次のとおりです。

CanCommit ステージと PreCommit ステージの後、決定結果は参加者間で調整され、保持されます。これは、2PC プロトコルの極端なケースで決定結果が誤って失われるのを回避するための優れた方法です。

2PC プロトコルでは、コーディネーターのみがタイムアウト メカニズムを備えていますが、3PC プロトコルでは参加者にもタイムアウト メカニズムが導入され、さまざまな段階で異なるタイムアウト処理が行われます。しかし、ネットワークの変動やネットワークの分割により、参加者のタイムアウト処理に新たな不確実性がもたらされ、データの不整合が発生する可能性もあります。

3PC プロトコルでは、問い合わせフェーズが 1 ラウンド追加されるため、全体的な対話プロセスは 2PC よりも長くなり、パフォーマンスは 2PC よりもわずかに低くなりますが、3PC プロトコルはネットワーク パーティションやその他の状況をうまく処理できません。

全体的に、3PC は 2PC に比べて多くの改善が行われ、一定の成果が得られていますが、データの不整合の問題がまだ残っており、さらなる努力が必要です。