【乾物シェアリング】分散コンセンサスプロトコル解説記事（前編）

この記事は「MOOC」から初公開されました IT雑貨やプログラマーサークルのホットニュースをもっと知りたい方は「MOOC」に注目！

著者: Daxiong 先生 | MOOC 講師

一般的な分散システムでは、マシンのダウンタイムやネットワークの異常 (メッセージの遅延、損失、重複、障害、ネットワークパーティションなど) などの状況が常に発生します。

コンセンサスアルゴリズムが解決する必要がある問題は、上記の異常が発生する可能性のある分散システムで、クラスター内の特定のデータの値について迅速かつ正確に合意し、上記のいずれかが発生しないことを保証する方法です。異常が発生しても、システム全体が破壊されることはありません。

CAP定理

CAP 理論では、分散システムが一貫性 (C: 一貫性)、可用性 (A: 可用性)、および分断耐性 (P: 分断耐性) の 3 つの基本要件を同時に満たすことは不可能であり、せいぜい満たすことしかできないとしています。同時に 3 つの基本的な要件 2.

オプション	説明
一貫性	複数のコピー間でデータの一貫性が保たれる（厳密な一貫性）という特性を指します。
可用性	これは、システムが提供するサービスが常に利用可能である必要があり、各要求に対してエラーのない応答を取得できることを意味します (ただし、取得したデータが最新のデータであるとは限りません)。
分割耐性	分散システムでネットワークパーティション障害が発生した場合でも、ネットワーク環境全体に障害が発生しない限り、一貫性と可用性を満たす外部サービスを提供できます。

基本理論

BASE：フルネーム：基本的に利用可能（基本的に利用可能）、ソフト状態（ソフト状態）、最終的に一貫性（最終的な一貫性）。

基本理論は、CAP における一貫性と可用性の間のトレードオフの結果であり、大規模なインターネット分散プラクティスの要約から導き出され、CAP 定理に基づいて徐々に進化しました。その核となる考え方は、たとえ強整合性 (強整合性) を達成することが不可能であっても、各アプリケーションは独自のビジネス特性に応じて適切な方法を使用して、システムに結果整合性 (結果整合性) を実現させることができるということです。

説明: ソフト状態とは? 原子性と比較して、複数のノードのデータコピーは一貫性を保つ必要があり、これは「ハードな状態」です。ソフト状態とは、システム内のデータが中間状態に存在することを許可し、この状態がシステムの全体的な可用性に影響を与えないと考えること、つまり、システムが複数の異なるデータのコピーでデータ遅延を発生させることを許可することです。ノード。

二相コミット 2PC

2 フェーズコミットプロトコル (Two-phase Commit、または 2PC) は、一般的に使用される分散トランザクションソリューションであり、トランザクションコミットプロセスを 2 つの段階に分割して処理します。フェーズ 2 では、フェーズ 1 の投票結果に応じて、トランザクションのコミットの実行とトランザクションの中断の 2 つの操作が実行されます。

役割

①コーディネーター：取引の発起人
②参加者：取引の執行者

ステージ1

事务询问: コーディネーターは、すべての参加者にトランザクションを実行する準備ができているかどうかを尋ね、各参加者の応答を待ち始めます。
执行事务: 各参加者ノードは、トランザクション操作を実行し、トランザクションログに Undo および Redo 情報を記録します。
各参与者向协调者反馈事务询问的响应: 参加者がトランザクション操作を正常に実行した場合、トランザクションを実行できることを示す Yes をコーディネーターにフィードバックします。参加者がトランザクションを正常に実行できなかった場合、トランザクションを実行できないことを示す No をコーディネーターに返します。実行されました。

ステージ2

フェーズ 2 では、フェーズ 1 の投票結果に応じて、トランザクションのコミットの実行とトランザクションの中断の 2 つの操作が実行されます。

トランザクションのコミット手順を実行する

发送提交请求: コーディネーターはすべての参加者にコミット要求を送信します。
事务提交: コミット要求を受け取った後、参加者は正式にトランザクションのコミット操作を実行し、コミットが完了した後、トランザクション実行全体で占有されていたトランザクションリソースを解放します。
反馈事务提交结果: 参加者は、トランザクションの送信を完了した後、コーディネーターに Ack メッセージを送信します。
协调者接收到所有参与者反馈的 Ack案内の後、お取引を完了してください。

割り込みトランザクションステップを実行します

发送回滚请求: コーディネーターはロールバック要求をすべての参加者に送信します。
事务回滚: ロールバック要求を受け取った後、参加者はステージに記録された Undo 情報を使用してトランザクションのロールバック操作を実行し、ロールバックが完了した後、トランザクション実行全体で占有されていたリソースを解放します。
反馈事务回滚结果: 参加者がトランザクションのロールバックを完了した後、コーディネーターに Ack メッセージを送信します。
中断事务: コーディネーターがすべての参加者からフィードバックされた Ack 情報を受信した後、トランザクションは中断されます。

CASE1 はコミットを実行します

CASE2 はロールバックを実行します

2 フェーズコミットの短所

2 フェーズコミットはアトミック操作を提供しているように見えますが、残念ながら、2 フェーズコミットにはまだいくつかの欠点があります。

ブロックの問題: 2PC サブミッションの実行中、トランザクション操作に関連するすべてのロジックがブロックされた状態になります。つまり、各参加者は他の参加者が応答するのを待っており、他の操作を実行できません。
単一点の問題:コーディネーターは単一点であり、問題が発生すると、他の参加者はトランザクションリソースを解放したり、トランザクション操作を完了したりできなくなります。
データに一貫性がありません。トランザクションのコミットプロセス中に、コーディネーターがすべての参加者にコミットリクエストを送信すると、コミットリクエストを送信する前にローカルネットワーク例外が発生するか、コーディネーターがクラッシュし、最終的に一部の参加者のみがリクエストを受信して実行します。その結果、システム全体でデータの不整合が発生します。
保守的。2PC には完全なフォールトトレラントメカニズムはありません. 参加者が失敗した場合、コーディネーターは失敗をすぐに知ることができず、タイムアウト設定に厳密に依存して、さらにコミットを実行するか、トランザクションを中断するかを決定することしかできません.

2 フェーズコミットには、同期ブロック、単一点の問題、スプリットブレインなどの欠点があるため、研究者は 2 フェーズコミットをベースに改良を加え、3 フェーズコミットを提案しました。

三相コミット 3PC

3 フェーズコミットプロトコル (3 フェーズコミットプロトコル) とも呼ばれる 3 フェーズコミット (3 フェーズコミット) は、2 フェーズコミット (2PC) の改良版です。

2 フェーズコミットとは異なり、3 フェーズコミットには 2 つの変更点があります。

タイムアウトメカニズムを導入します。同時に、コーディネーターと参加者の両方にタイムアウトメカニズムが導入されます。
第 1 段階と第 2 段階の間に準備段階が挿入されます。最終的なコミットフェーズの前に、参加している各ノードの状態が一貫していることが保証されます。

つまり、タイムアウトメカニズムの導入に加えて、3PC は 2PC の準備フェーズをさらに 2 つに分割し、3 フェーズコミットに CanCommit、PreCommit、および DoCommit の 3 つのフェーズがあるようにします。

CanCommit ステージ

3PC の CanCommit 段階は、実際には 2PC の準備段階と非常によく似ています。コーディネーターは参加者にコミット要求を送信し、参加者はサブミットできる場合は Yes 応答を返し、サブミットできない場合は No 応答を返します。

トランザクションクエリコーディネーターは CanCommit 要求を参加者に送信します。トランザクションのコミット操作を実行できるかどうかを尋ねます。次に、参加者の応答を待ち始めます。
応答フィードバック参加者が CanCommit リクエストを受信した後、通常、トランザクションがスムーズに実行できると判断した場合、参加者は Yes 応答を返し、準備完了状態になります。そうでなければフィードバックいいえ

PreCommit ステージ

コーディネーターは、canCommit フェーズの参加者の応答に従って、トランザクションの PreCommit 操作を続行するかどうかを決定します。応答に応じて、2 つの可能性があります。

コーディネーターが CanCommit フェーズですべての参加者から Yes の応答を受け取った場合、トランザクションの事前実行が実行されます。

事前コミット要求を送信する: コーディネーターは参加者に PreCommit 要求を送信し、準備フェーズに入ります。
Transaction pre-commit : PreCommit リクエストを受け取った後、参加者はトランザクション操作を実行し、取り消しとやり直しの情報をトランザクションログに記録します。
応答フィードバック: 参加者がトランザクション操作を正常に実行すると、ACK 応答を返し、最終コマンドの待機を開始します。

canCommit フェーズのいずれかの参加者がコーディネーターに No 応答を送信するか、タイムアウトを待った後、コーディネーターが参加者からの応答を受信しない場合、トランザクションは中断されます。

中止リクエストの送信:コーディネーターはすべての参加者に中止リクエストを送信します。
トランザクションの中断:参加者がコーディネーターから中止要求を受け取った後 (または、タイムアウトの後、コーディネーターからの要求がまだ受信されていない場合)、トランザクションは中断されます。

doCommit ステージ

この段階でコミットされる実際のトランザクションも、次の 2 つの状況に分けることができます。

コミットを実行

コミット要求の送信:コーディネーターは preCommit 段階で参加者によって送信された ACK 応答を受信し、参加者は precommit 状態から commit 状態に入ります。そして、すべての参加者に doCommit リクエストを送信します。
トランザクションの送信:参加者は doCommit 要求を受信した後、正式なトランザクションの送信を実行します。トランザクションのコミットが完了したら、すべてのトランザクションリソースを解放します。
応答フィードバック:トランザクションがコミットされた後、Ack 応答をコーディネーターに送信します。
トランザクションの完了:コーディネーターがすべての参加者から ack 応答を受信すると、トランザクションが完了します。

割り込みトランザクションコーディネーターが preCommit フェーズで参加者によって送信された ACK 応答を受信しない場合 (受信者が ACK 応答を送信しなかったか、応答がタイムアウトした可能性があります)、割り込みトランザクションが実行されます。

Send an abort request : コーディネーターがすべての参加者に中止リクエストを送信します
トランザクションのロールバック:中止要求を受け取った後、参加者はフェーズ 2 で記録された元に戻す情報を使用してトランザクションのロールバック操作を実行し、ロールバックの完了後にすべてのトランザクションリソースを解放します。
フィードバック結果:参加者がトランザクションのロールバックを完了した後、コーディネーターに ACK メッセージを送信します 4. 中断トランザクションコーディネーターは、参加者からフィードバックされた ACK メッセージを受信した後、トランザクションの中断を実行します。

doCommit フェーズでは、参加者がコーディネーターからの doCommit または中止要求を時間内に受信できなかった場合、タイムアウトを待ってからトランザクションのコミットを続行します。(実際には、これは確率に基づいて決定する必要があります。第 3 段階に入る場合、参加者は第 2 段階で PreCommit 要求を受信したことを意味するため、コーディネーターが PreCommit 要求を生成するための前提条件は、PreCommit を受信することです。すべての参加者に対する CanCommit の応答は Yes です (参加者が PreCommit を受け取ると、参加者は全員が実際にそれを変更することに同意したことを知っていることになります)。ネットワークのタイムアウトやその他の理由により、参加者はコミットまたは中止の応答を受信しませんが、送信が成功する可能性が非常に高いと信じる理由があります。)

3 フェーズコミットの長所と短所:

3PC は、2PC によってもたらされた参加者のブロック範囲を効果的に縮小し、単一障害点が発生した後もコンセンサスに到達し続けることができます; しかし、3PC は
新しい問題をもたらします. 参加者が preCommit メッセージを受信した後、ネットワークパーティションが発生した場合、コーディネーターは後続の通信この場合、参加者はタイムアウトを待ってからトランザクションのコミットを実行するため、データの不整合が発生します。

Paxos アルゴリズム

2PC と 3PC の両方がコーディネーターの役割を導入する必要があります.コーディネーターがダウンすると、トランザクション全体を送信できず、参加者のリソースがロックされます.システムへの影響は壊滅的であり、ネットワークパーティションが発生します.この場合、データ不一致が発生する可能性があります。コーディネーターの役割を必要とせず、各参加者がトランザクションを調整し、ネットワークパーティションの場合は一貫性を最大限に保証できるソリューションはありますか。この時点で Paxos が登場しました。

Paxos アルゴリズムは、1990 年に Lamport によって提案されたメッセージパッシングに基づくコンセンサスアルゴリズムです。アルゴリズムは理解しにくく、最初は人々の注目を集めなかったため、8 年後にランポートが再公開しましたが、それでも Paxos アルゴリズムは注目を集めることはありませんでした。2006 年に Google が発表した 3 つの論文は衝撃的でしたが、その中で chubby lock サービスは chubbycell の一貫性として Paxos を使用し、後に注目されました。

Paxos プロトコルは、分散システム内の複数のノード間で、ある値 (提案) についてコンセンサス (解決) を解決する通信プロトコルです。少数のノードがオフラインである場合でも、残りの大多数のノードが合意に達することができます。つまり、各ノードは参加者であり、意思決定者でもあります

パクソスの役割

Paxos プロトコルの役割には、主に次の 3 種類のノードが含まれます。

提案者: 値を提案します。
アクセプター: 各提案に投票します。
情報提供者 (学習者): 投票プロセスに参加するのではなく、投票の結果を通知されること。

アルゴリズムの説明

- 第一阶段

   [a]: Proposer提出提案，編号Mn，并向过半数Acceptor发送編号Mn的Prepare请求。
   [b]: 如果Acceptor收到的Prepare请求的编号Mn > 其己答复的任何Prepare请求的编号，则Acceptor对该请求作出答复，并承诺不接受任何编号小于編号Mn的提案

- 第二阶段

   [a]: 如果Proposer从过半数Acceptor处收到对其Prepare请求（編号n）的响应，则向这些Acceptor发送一个Accept请求[Mn,Vn]，其中Vn是响应中编号最高的提案的值，或者如果响应报  告没有提案，则Vn是任何值。
   [b]:如果Acceptor收到Accept请求[Mn,Vn]，若该Acceptor尚未对编号大于Mn的Prepare请求作出过响应，则通提案。

通常のケース提案の選択

状況 1: S3 は最初に S1 の値を受け入れ、Accept ack を返し、S5 の提案を確認します。

重要な点は、S3 も S5 からの準備提案を受け取っているということですが、この時点で矛盾はありますか?

S3 は、以前に受信した提案変更番号 1 と値 x で S5 に応答し、S5 は Y を X に置き換え、番号 2、x をブロードキャストに適用します。

ケース 2: s3 は最初に S1 の値を受け入れ、次に S5 の提案を見て、Accept の ack を返します。

**要点:** S3 は S5 の準備提案も受けていますが、この時点で矛盾はありますか?

状況 3: S3 は、Accept ステージを通過する前に S5 から準備提案を受け取りました。

重要な点は、S3 が Accept ステージを通過する前に、S5 から準備提案を取得したことですが、この時点で矛盾はありますか?

この場合、S1 の提案は適用されず、新しいラウンドの提案を再開する必要があります。

ケース 4: ライブロックの形成

元の Paxos アルゴリズム (Basic Paxos) は 1 つの値の解決しか形成できません. 解決の形成には少なくとも 2 つのネットワークラウンドトリップが必要です. 同時実行性が高い状況では、より多くのネットワークラウンドトリップが必要になる場合があります. 極端な場合には、ライブロックが発生する可能性があります形成されることさえあります。

Paxos は複数の提案者を許可するため、上の図のように実行すると、後者の提案は常に前の提案の選択に失敗し、明らかに無限ループになります。

ようこそ「MOOC」アカウントへようこそ! 私たちは常に独自のコンテンツにこだわり、IT サークルで高品質のコンテンツを提供し、ドライな知識を共有します. 一緒に成長しましょう!

この記事はもともと Muke.com で公開されたものです。転載の際は出典を示してください。ご協力いただきありがとうございます