データの一貫性を実現するための分散トランザクション XA のプロトコルと原理の詳細な説明 - 2PC と 3PC

概要

大規模なビジネス システムには、多数のユーザーと高い同時実行性という特徴があります。この点では、集中型データベース（スタンドアロン データベース）のパフォーマンスをサポートするのは困難です。そのため、主流のインターネット企業は、ビジネスニーズに対応するために、よりローエンドのデバイスを物理的に活用し、大きなテーブルを論理的に水平に分割する分散型（アーキテクチャ）データベースを採用することがよくあります。

分散データベースはパフォーマンスの問題を解決できますが、トランザクションの一貫性の問題は分散データベースでは解決が困難です。

データの一貫性?

一貫性の問題、つまり「諸悪の根源」は、データの冗長性と分散、そしてネットワークを介した相互作用であり、ネットワークの異常は当たり前のことです。

1. データ一貫性シナリオ

マスター データベース、スレーブ データベース、およびキャッシュ データの一貫性、同一データの冗長性、リレーショナル データベースでは、データベースの高可用性と高性能を確保するために、通常、マスター スレーブ (バックアップ) アーキテクチャを採用し、キャッシュを導入します。データの不整合は、データ冗長性の時間枠内に存在します。一般的に使用されるソリューションについては、「データベース用の一般的なインターネット アーキテクチャ ソリューション」を参照してください。

ビッグデータの分野では、データの複数のコピー、同じデータのコピー間のデータの一貫性は、1 つのデータに複数のコピーが存在し、異なるノードに保存されます。クライアントは読み取りおよび書き込み操作のために任意のノードにアクセスできます。一般的なソリューションは、Paxos、ZAB、Raft、Quorum、Gossip などのオープンソース実装に基づいています。

分散サービス間のデータの一貫性、関連データの分散、分散サービス、異なるサービスが異なるライブラリ (テーブル) を操作し、ライブラリ (テーブル) の一貫性を維持する必要があります。一般的に使用されるソリューションは、分散トランザクション一貫性ソリューションです。

2. データの一貫性の概念

強い一貫性

一貫性が弱い

最終的な一貫性

3. データ一貫性の原則

酸

キャップ

ベース

4. データ一貫性プロトコル

• 2 フェーズ コミット プロトコル
• 3相コミットプロトコル
• TCC プロトコル
• パクソスプロトコル
• ZABプロトコル
• ラフトプロトコル
• クォーラムプロトコル
• ゴシッププロトコル

分散トランザクションXAはデータの一貫性を実現します

いわゆる分散サービスとは、以前はローカル インターフェイスを介して対話していたモジュールを個別のアプリケーションに分割し、それらを独立して展開し、RPC および MQ を介して対話することです。物流における注文と在庫を例に挙げます（新しい注文レコードが追加されると、在庫は -1 になります）。集中型アーキテクチャでは、注文テーブルと在庫テーブルの一貫性を保証するために、1 つのローカル トランザクション (ACID) だけで 2 つのテーブルの強い一貫性を保証できます。一方、分散アーキテクチャでは、注文テーブルは注文サービスによって操作され、在庫テーブルは在庫サービスによって操作されます。注文テーブルと在庫テーブルの一貫性を確保するには、注文テーブルに対する注文サービスの操作と在庫テーブルに対する在庫サービスの操作が同時に成功することを保証する必要があります。以前のローカル トランザクションは分散トランザクションになります。サービス間のネットワーク相互作用とネットワーク異常は当たり前のことなので、サービス間でデータの不整合が発生します。これには、分散トランザクションの一貫性の問題が関係します。

業界には、分散トランザクションの ACID を保証するための比較的成熟したソリューションもあり、一般的には 2 フェーズ コミット (2PC) プロトコル、またはその改良版である 3 フェーズ コミット (3PC) プロトコルが使用されています。以下にそれぞれの簡単な紹介をします。

2PC プロトコルは、2 フェーズ コミット (1 つの準備フェーズ、2 つのコミット フェーズ) とも呼ばれます。

いわゆる 2 つの段階とは、第 1 段階: 準備段階 (投票段階)、第 2 段階: 提出段階 (実行段階) を指します。

準備

トランザクション コーディネーター (トランザクション マネージャー) は、各参加者 (リソース マネージャー) に準備メッセージを送信します。各参加者は、直接失敗を返すか (権限検証の失敗など)、トランザクションをローカルで実行し、ローカルの redo ログと undo ログを書き込みますが、コミットは行わず、「すべて準備完了、東風だけが足りない」という状態になります。

準備フェーズはさらに次の 3 つのステップに分けられます。

1) コーディネーターノードは、すべての参加ノードに送信操作（投票）を実行できるかどうかを問い合わせ、各参加ノードの応答を待ち始めます。

2) 参加ノードは、クエリが開始されるまでのすべてのトランザクション操作を実行し、元に戻す情報とやり直し情報をログに書き込みます。 (注: 成功した場合、各参加者は実際にトランザクション操作を実行したことになります)

3) 各参加ノードはコーディネーターノードによって開始されたクエリに応答します。参加ノードのトランザクション操作が実際に正常に実行された場合、「承認」メッセージが返されます。参加ノードのトランザクション操作が実際に実行されなかった場合、「中止」メッセージが返されます。

提出フェーズ

コーディネータが参加者から失敗メッセージまたはタイムアウトを受信した場合、各参加者にロールバックメッセージを直接送信します。それ以外の場合はコミット メッセージを送信します。参加者はコーディネータの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理プロセスで使用されるすべてのロック リソースを解放します。 (注: ロック リソースは最終段階で解放する必要があります)

次に、2 つの状況における提出フェーズのプロセスについて説明します。

コーディネーターノードがすべての参加ノードから「同意」応答を受信すると、次のようになります。

1) コーディネーターノードは、すべての参加ノードに「正式なコミット」要求を送信します。

2) 参加ノードは正式に操作を完了し、トランザクション全体で占有されていたリソースを解放します。

3) 参加ノードはコーディネーターノードに「完了」メッセージを送信します。

4) コーディネーターノードがすべての参加ノードから「完了」メッセージを受信すると、トランザクションが完了します。

最初のフェーズでいずれかの参加ノードから返された応答メッセージが「abort」の場合、またはコーディネーター ノードが最初のフェーズのクエリ タイムアウト前にすべての参加ノードの応答メッセージを取得できない場合は、次のようになります。

1) コーディネーターノードは、すべての参加ノードに「ロールバック」要求を送信します。

2) 参加ノードは、以前に書き込まれた元に戻す情報を使用してロールバックを実行し、トランザクション全体で占有されていたリソースを解放します。

3) 参加ノードはコーディネーターノードに「ロールバック完了」メッセージを送信します。

4) コーディネーターノードは、すべての参加ノードから「ロールバック完了」メッセージを受信すると、トランザクションをキャンセルします。

最終的な結果に関係なく、第 2 フェーズでは現在のトランザクションが終了します。

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

1. 同期ブロッキングの問題。実行プロセス中、参加しているすべてのノードはトランザクションをブロックします。参加者がパブリック リソースを占有する場合、他のサードパーティ ノードがパブリック リソースにアクセスできないようにブロックする必要があります。

2. 単一障害点。コーディネーターの重要性により、コーディネーターが失敗すると。参加者はブロックを継続します。特に第 2 フェーズでは、コーディネーターが失敗すると、すべての参加者がトランザクション リソースをロックした状態のままになり、トランザクション操作を完了し続けることができません。 (コーディネーターが失敗した場合、新しいコーディネーターが再選されますが、コーディネーターの失敗により参加者がブロックされる問題は解決されません。)

3. データに矛盾があります。 2 フェーズ コミットのフェーズ 2 では、コーディネータが参加者にコミット要求を送信した後、コミット要求の送信プロセス中にローカル ネットワークの異常が発生するか、コーディネータに障害が発生し、その結果、一部の参加者のみがコミット要求を受信することになります。コミット要求を受信すると、これらの参加者はコミット操作を実行します。ただし、コミット要求を受信して​​いない他のマシンはトランザクションのコミットを実行できません。その結果、分散システム全体でデータの不整合が発生しました。

4. 第 2 フェーズで解決できない問題: コミット メッセージを送信した後にコーディネーターがクラッシュし、このメッセージを受信した唯一の参加者も同時にクラッシュします。その後、コーディネーターが選挙プロトコルを通じて新しいコーディネーターを生成したとしても、このトランザクションのステータスは不確実であり、トランザクションが送信されたかどうかは誰にもわかりません。

2 フェーズ コミットには、同期ブロッキング、シングル ポイント問題、ブレイン スプリットなどの欠陥があるため、2 フェーズ コミットをベースに改良が行われ、3 フェーズ コミットが提案されました。

パソコン

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

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

1. タイムアウトメカニズムを導入します。同時に、コーディネーターと参加者の両方にタイムアウト メカニズムが導入されます。

2. 最初のフェーズと 2 番目のフェーズの間に準備フェーズを挿入します。これにより、最終的な送信フェーズの前に、参加している各ノードのステータスが一貫していることが保証されます。

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

CanCommit ステージ

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

1. トランザクション クエリ コーディネータは、参加者に CanCommit 要求を送信します。トランザクションのコミット操作を実行できるかどうかを尋ねます。次に、参加者の反応を待ち始めます。

2. 応答フィードバック CanCommit 要求を受信した後、通常の状況では、参加者はトランザクションが正常に実行できると判断した場合、Yes 応答を返し、準備完了状態になります。それ以外の場合はフィードバックなし

事前コミットフェーズ

コーディネーターは、参加者の応答に基づいて、トランザクションの PreCommit 操作を記憶するかどうかを決定します。応答に応じて 2 つの可能性があります。

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

1. 事前コミット要求を送信する コーディネーターは参加者に PreCommit 要求を送信し、準備フェーズに入ります。

2. PreCommit 要求を受信した後、トランザクションの事前コミット参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します。

3. 応答フィードバック 参加者がトランザクション操作を正常に実行すると、ACK 応答が返され、参加者は最終指示の待機を開始します。

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

1. 中断要求を送信する コーディネータはすべての参加者に中止要求を送信します。

2. トランザクション参加者がコーディネータから中止要求を受信した後（またはタイムアウト後もコーディネータからの要求を受信しない場合）、トランザクションは中断されます。

doCommitフェーズ

このフェーズは実際のトランザクションがコミットされるフェーズであり、次の 2 つの状況に分けられます。

実行 送信

1. コミット要求を送信し、参加者から送信された ACK 応答の受信を調整すると、参加者はコミット前状態からコミット状態に移行します。そして、すべての参加者に doCommit リクエストを送信します。

2. doCommit 要求を受信した後、トランザクション コミット参加者は正式なトランザクション コミットを実行します。トランザクションのコミットが完了したら、すべてのトランザクション リソースを解放します。

3. 応答フィードバック トランザクションが送信されると、Ack 応答がコーディネータに送信されます。

4. トランザクションコーディネーターがすべての参加者から ack 応答を受信すると、トランザクションが完了します。

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

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