分散トランザクションとは何ですか? また、そのソリューションは何ですか?

分散トランザクションとは何ですか?

回答: 大規模な操作はさまざまな小規模な操作で構成されていることを意味します。これらの小さな操作は、異なるサーバーに分散されます。分散トランザクションでは、これらの小さな操作がすべて成功するか、すべて失敗するかを保証する必要があります。本質的に、分散トランザクションは、異なるデータベース間でのデータの一貫性を確保するように設計されています。

分散トランザクションの原因は何ですか?

1 データベースシャーディング

データベースの単一テーブル内のデータが数千万に達すると、データベースとテーブルを分割して、元の 1 つのデータベースを複数のデータベースに分割することを検討する必要があります。たとえば、操作がデータベース 01 とデータベース 02 の両方を操作し、データの一貫性を保証する必要がある場合は、分散トランザクションを使用する必要があります。

2 アプリケーションSOA

いわゆる SOA はサービス指向ビジネスを意味します。たとえば、電子商取引プラットフォームで注文を行うと、在庫を減算するために在庫サービスが呼び出され、注文データを更新するために注文サービスが呼び出されます。この場合、注文データベースと在庫データベースが関係します。データの一貫性を確保するには、分散トランザクションが必要です。

要約: 実際、上記の 2 つのシナリオは、最終的には複数のデータベースを操作し、データの一貫性を確保して、分散トランザクションを生成することを目的としています。

分散トランザクションソリューション

1. 2フェーズコミット（2PC）

XA は、Tuxedo によって提案された分散トランザクションプロトコルです。 XA は、トランザクションマネージャーとローカルリソースマネージャーの 2 つの部分に大まかに分かれています。ローカルリソースマネージャーは、多くの場合、データベースによって実装されます。たとえば、Oracle、MySQL、およびその他のデータベースはすべて XA インターフェイスを実装しており、トランザクションマネージャーはグローバルスケジューラとして各ローカルリソースのコミットとロールバックを担当します。

分散トランザクションを実装する XA の原則は次のとおりです。

要約する

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

同期ブロッキング問題: 実行プロセス中、参加しているすべてのノードはトランザクションブロッキングタイプです。参加者がパブリックリソースを占有する場合、他のサードパーティノードがパブリックリソースにアクセスできないようにブロックする必要があります。
単一障害点: (トランザクションマネージャー) コーディネーターの重要性により、コーディネーターに障害が発生すると、 (ローカルリソースマネージャー) 参加者は無期限にブロックされます。特に第 2 フェーズでは、コーディネーターが失敗すると、すべての参加者がトランザクションリソースをロックした状態のままになり、トランザクション操作を完了し続けることができません。 (コーディネーターが失敗した場合、新しいコーディネーターが再選されますが、コーディネーターの失敗により参加者がブロックされる問題は解決されません。)
データの不整合: 2 フェーズコミットのフェーズ 2 では、コーディネーターが参加者にコミット要求を送信した後、ローカルネットワークの異常が発生するか、コミット要求の送信プロセス中にコーディネーターが失敗し、その結果、一部の参加者のみがコミット要求を受信することになります。コミット要求を受信すると、これらの参加者はコミット操作を実行します。ただし、コミット要求を受信していない他のマシンはトランザクションのコミットを実行できません。その結果、分散システム全体でデータの不整合が発生しました。
第 2 フェーズで解決できない問題: 参加者がコミットメッセージを送信した後にクラッシュし、このメッセージを受信した唯一のコーディネーターも同時にクラッシュします。その後、コーディネーターが選挙プロトコルを通じて新しいコーディネーターを生成したとしても、このトランザクションのステータスは不確実であり、トランザクションが送信されたかどうかは誰にもわかりません。

2. 3相コミット（3PC）

3PC は実際には 2PC に基づいて CanCommit ステージを追加します。これは 2PC のバリエーションであり、タイムアウトメカニズムを導入します。トランザクション参加者がコーディネータからのコミット要求を受信できない場合、自動的にローカルコミットが実行され、コーディネータの単一障害点の問題が効果的に解決されます。ただし、パフォーマンスとデータの一貫性の問題は根本的に解決されていません。

3PCはCanCommit、PreCommit、DoCommitの3つの段階に分かれています。

CanCommit ステージ

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

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

事前コミットフェーズ

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

コーディネーターがすべての参加者から Yes 応答を受け取った場合、トランザクションが実行されます。
事前コミット要求を送信する: コーディネーターは参加者に PreCommit 要求を送信し、準備フェーズに入ります。
トランザクションの事前コミット: PreCommit 要求を受信した後、参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクションログに記録します。
応答フィードバック: 参加者がトランザクション操作を正常に実行すると、ACK 応答が返され、参加者は最終指示の待機を開始します。
いずれかの参加者がコーディネータに「いいえ」応答を送信した場合、待機時間がタイムアウトした場合、またはコーディネータが参加者からの応答を受信しなかった場合、トランザクションは中断されます。
中止要求を送信する: コーディネーターはすべての参加者に中止要求を送信します。
トランザクションの中断: 参加者がコーディネータから中止要求を受信した後 (またはタイムアウト後もコーディネータからの要求を受信しない場合)、トランザクションは中断されます。

doCommitフェーズ

このフェーズは実際のトランザクションをコミットするために使用され、次の 2 つの状況に分けることができます。

実行送信
コミット要求を送信します。コーディネーションは、参加者から送信された ACK 応答を受信すると、コミット前状態からコミット状態に入ります。そして、すべての参加者に doCommit リクエストを送信します。
トランザクションのコミット: doCommit 要求を受信した後、参加者は正式なトランザクションのコミットを実行し、トランザクションのコミットが完了した後にすべてのトランザクションリソースを解放します。
応答フィードバック: トランザクションがコミットされると、ACK 応答がコーディネータに送信されます。
トランザクションを完了する: コーディネーターがすべての参加者から ACK 応答を受信すると、トランザクションが完了します。
トランザクションの中断
コーディネータが参加者から送信された ACK 応答を受信しない場合 (受信者が ACK 応答を送信しなかったか、応答がタイムアウトした可能性があります)、トランザクションは中断されます。
中止要求を送信: コーディネータはすべての参加者に中止要求を送信します
トランザクションロールバック: 中止要求を受信した後、参加者はフェーズ 2 で記録された元に戻す情報を使用してトランザクションロールバック操作を実行し、ロールバックが完了したらすべてのトランザクションリソースを解放します。
フィードバック結果: 参加者がトランザクションのロールバックを完了すると、コーディネータに ACK メッセージを送信します。
トランザクションを中断する: コーディネータは参加者からフィードバックされた ACK メッセージを受信すると、トランザクションを中断します。

概略図は以下のとおりです。

要約する

2PC と比較すると、3PC はコーディネータと参加者の両方にタイムアウトを設定しますが、2PC ではコーディネータのみにタイムアウトメカニズムがあります。この最適化により、参加者が独自のタイムアウトメカニズムを持ち、タイムアウト後にリソースを解放するためのローカルコミットを自動的に行うため、参加者がコーディネーターノードと長時間通信できない場合にリソースを解放できないという問題が解決されます。このメカニズムにより、トランザクション全体のブロック時間と範囲も間接的に削減されます。しかし、データの一貫性の問題はまだ解決されていません。つまり、参加者がPreCommitリクエストを受信して最終指示を待つときに、コーディネーターがこの時点で参加者と正常に通信できない場合、参加者はトランザクションを送信し続け、データの不整合が発生します。

3. 補償取引（TCC）

TCC (Try-Confirm-Cancel) は補償取引とも呼ばれます。実際のところ、これは 2PC や 3PC と同様に、分散トランザクションの単なる実装です。これは 3 つの操作に分かれています。

試行フェーズ: 主にビジネスシステムをテストし、リソースを予約します。
確認フェーズ: 業務遂行の実行を確認します。
キャンセルステージ: ビジネス操作をキャンセルします。

TCC トランザクションの処理フローは 2PC 2 フェーズコミットの処理フローと似ていますが、2PC は通常 DB レベルであるのに対し、TCC は基本的にアプリケーションレベルの 2PC であり、ビジネスロジックを通じて実装する必要があります。その利点は、アプリケーション自体がデータベース操作の粒度を定義できるため、ロックの競合と送信スループットが削減されることです。

ただし、これはアプリケーションに非常に影響を及ぼし、ビジネスロジックの各ブランチで、試行、確認、キャンセルの 3 つの操作を実装する必要があります。

TCC の回路図は次のとおりです。

4. メッセージトランザクション + 最終的な一貫性

いわゆるメッセージトランザクションは、メッセージミドルウェアに基づく 2 フェーズコミットです。本質的には、ミドルウェアの特別な使用法です。ローカルトランザクションとメッセージ送信を分散トランザクションに配置して、ローカル操作が成功し、外部メッセージ送信が成功するか、または両方が失敗することを保証します。オープンソースの RocketMQ はこの機能をサポートしています。具体的な原則は次のとおりです。

手順は次のとおりです。

サービス A は、メッセージミドルウェアに準備メッセージを送信します。
メッセージミドルウェアは準備されたメッセージを保存し、成功を返します。
サービス A はローカルトランザクションを実行します。
サービス A はメッセージミドルウェアにコミットメッセージを送信し、サービス B はメッセージを受信した後にローカルトランザクションを実行します。

メッセージミドルウェアに基づく 2 フェーズコミットは、同時実行性の高いシナリオでよく使用されます。分散トランザクションをメッセージトランザクション (サービス A のローカル操作 + メッセージの送信) + サービス B のローカル操作に分割します。サービス B の操作はメッセージによって実行されます。メッセージトランザクションが成功する限り、サービス A は成功し、メッセージが送信される必要があります。このとき、サービス B はローカル操作を実行するためのメッセージを受信します。ローカル操作が失敗した場合、サービス B の操作が成功するまでメッセージは再送信されます。このようにして、A と B の分散トランザクションが偽装されて実現されます。

上記の手順では異常な状況が発生する可能性があり、現在分析中です。

ステップ 1 でエラーが発生すると、トランザクション全体が失敗し、サービス A のローカル操作は実行されません。
ステップ 2 でエラーが発生すると、トランザクション全体が失敗し、サービス A のローカル操作は実行されません。
ステップ 3 でエラーが発生します。準備されたメッセージをロールバックする必要があります。サービス A は、メッセージミドルウェアのコールバックインターフェイスを実装します。メッセージミドルウェアは、コールバックインターフェイスを継続的に実行して、サービス A のトランザクションが正常に実行されたかどうかを確認します。失敗した場合、準備されたメッセージはロールバックされます。
ステップ 4 でエラーが発生します。この時点では、サービス A のローカルトランザクションは成功していますが、メッセージミドルウェアをロールバックする必要はありません。実際、コールバックインターフェイスを通じて、メッセージミドルウェアはサービス A が正常に実行されたことを確認できます。現時点では、サービスはコミットメッセージを送信する必要はありません。メッセージミドルウェアはメッセージを単独で送信できるため、メッセージトランザクション全体が完了します。

<<: エッジコンピューティングはネットワーク攻撃対象領域を拡大させる可能性がある

>>: クラウド2.0時代のクラウドコンピューティング大手間の競争は加速している