分散トランザクションのソリューションを1つの記事で理解する

[[407680]]

単一のデータベースではネットワークのやり取りが不要なので、複数のテーブル間でトランザクションを実装するのは比較的簡単です。このタイプのトランザクションはローカル トランザクションと呼ばれます。

ただし、単一のデータベースのパフォーマンスがボトルネックに達すると、データベースを分割する必要があり、データベース間 (データベース インスタンス) トランザクション要件が発生します。エンタープライズアプリケーションの規模が拡大するにつれて、企業はビジネスの成長のニーズを満たすためにサービス指向の変革をさらに進めることになります。現在、マイクロサービス アーキテクチャはますます普及しており、サービス間のトランザクション シナリオも増加しています。

これらはすべて分散トランザクションです。分散トランザクションとは、トランザクションの開始者、参加者、データ リソース サーバー、およびトランザクション マネージャーが分散システムの異なるノードに配置されていることを意味します。

要約すると、分散トランザクションには 3 つのシナリオがあります。

1. データベース間の分散トランザクション

2. サービス間の分散トランザクション

3. ハイブリッド分散トランザクション

この記事では、分散トランザクションの一般的なソリューションを紹介します。

1. 2PC

2. 3PC

3. TCC

4. サガトランザクション

5. ローカルメッセージテーブルメカニズムに基づく

6. トランザクションメッセージメカニズムに基づく

7. ベストエフォート通知メカニズム

一般的な解決策

分散トランザクションは複数のローカル トランザクションで構成されます。分散トランザクションは複数のデバイスにまたがり、複雑なネットワークを通過します。厳格な取引の実施までの道のりは長く困難であると考えられます。

2PC

2 フェーズ コミット (2PC) とは、トランザクションをコミットするときに、分散システム アーキテクチャ内のすべてのノード間の一貫性を確保するように設計されたアルゴリズムを指します。

図に示すように、全体のプロセスは 2 つの段階に分かれています。

2PCのメリットとデメリット

2PC の利点は、参加者 (RM) 自体の機能を使用して、ビジネス ロジックに一切干渉することなく、ローカル トランザクションをコミットおよびロールバックできることです (TCC ソリューションと比較して)。

ただし、2PC には、同期のブロック、単一点障害、データの不整合という 3 つの大きな欠点もあります。

1. 同期ブロッキング

参加者 (RM) は操作を実行するときに同期的にブロックされるため、2PC プロセス中にロックされたリソースにアクセスするときは他のノードをブロックする必要があります。

2. 単一障害点

コーディネーター (TM) は単一のポイントであり、コーディネーターが失敗すると、参加者は永久にブロックされます。ホットスポット リソースがブロックされると、システム全体に影響が及ぶ可能性があります。

3. データの不整合の問題

第 2 フェーズでは、ネットワーク上の理由により、一部の参加者 (RM) がコーディネーター (TM) から情報を受信しなかったか、一部の参加者がコミット/ロールバック操作の実行時に例外に遭遇しました。これにより、データの不整合の問題が発生します。

2PC最適化

Percolator は、BigTable 上に構築され、Google 内でウェブ インデックスの更新操作に使用される、Google の前世代の分散トランザクション ソリューションです。原論文は参考文献4に掲載されています。

TiDB のトランザクション モデルは Percolator のトランザクション モデルに従います。これについては、分散データベースに関する次のブログ投稿で説明します。

3PC

2PC と比較して、3PC には 3 段階モードとタイムアウト メカニズムが追加されています。

タイムアウト メカニズム: 第 3 フェーズでは、参加者がコーディネータから長時間応答を受信しない場合、デフォルトでは、参加者はタイムアウトしたトランザクションを自動的にコミットします (コーディネータがロールバック コマンドを送信してデータの不整合が発生する場合でも)。 2PC 同期ブロッキングの問題を解決します。

同時に、3PC は第 1 段階のクエリ通知を追加して、2PC でのデータ不整合の問題の可能性を減らします。

ただし、3PC では 2PC の単一点障害の問題が解決されません。

3PC の 3 つの段階を図に示します。

1. フェーズ 1、CanCommit

2. フェーズ2: 事前コミット

3. フェーズ3、DoCommit

要約する

2PC と 3PC はどちらもプロトコルであり、指導理念であり、プロジェクトにおける実際の実施計画とは異なります。

ただし、トランザクション処理中にコーディネーターが複数のデータベース (RM) に同時に接続する必要があるため、2PC と 3PC は大規模な分散システムではほとんど使用されません。

通常、マイクロサービスはそれぞれの分野のデータベースに接続されます。マイクロサービスが別のフィールドのデータを変更する場合は、RPC インターフェースを介して実装する必要があり、複数のデータ ソースにはアクセスされません。複数のデータソースをリンクするコーディネーターが多すぎると、必然的にサービスガバナンスの難易度が高まり、データの混乱が発生する可能性があります。

TCC

2PC と 3PC はどちらも、データベース トランザクションのコミットとロールバックに依存します。

しかし、テキスト メッセージの送信、写真のアップロード、その他のビジネス レイヤー ロジックなど、一部のビジネスではデータベース以外の処理も必要になる場合があります。

したがって、トランザクションの送信とロールバックは、データベース レベルではなくビジネス レベルに引き上げる必要があり、TCC はビジネス レベルでの 2 フェーズ コミットです。

TCC (Try、Commit、Cancel) は補償トランザクションです。このモデルでは、アプリケーションの各サービスが、試行、確認、キャンセルの 3 つのインターフェースを提供する必要があります。中心となる考え方は、まずリソースの予約を評価することです。トランザクションをコミットできる場合、予約されたリソースが確認されます。トランザクションをロールバックする必要がある場合、予約されたリソースは解放されます。

TCC は基本的にアプリケーション レベルの 2PC であり、次の図に示すように 2 つのステージに分かれています。

たとえば、控除サービスが TCC を使用する場合、資金を控除するための Try メソッドを記述する必要があります。実際の推論を実行するには Confirm メソッドも必要です。最後に、減算操作をロールバックするための Cancel メソッドを提供する必要があります。

元の方法を3つの方法に拡張する必要があることがわかり、TCCはビジネスに大きな侵入を持っています。

TCC はビジネスに侵入しますが、リソースをブロックすることはありません。各メソッドはトランザクションを直接送信します。エラーが発生した場合は、ビジネス レベルでのキャンセルによって補正されます。したがって、TCC は補償取引です。

2PC の単一点障害またはタイムアウトの問題に対する TCC の解決策は再試行を続けることです。つまり、応答を受信して​​いない Confirm/Cancel インターフェイスを、成功するまで再試行し続けます。再試行戦略が失敗した場合、ログ記録とアラームを通じて手動介入が実行されます。

ただし、この再試行メカニズムにより、TCC のべき等性問題と空のロールバック問題が発生します。

注意が必要なTCCの問題

1. べき等性問題

再調整メカニズムのため、繰り返し実行によるエラーを回避するために、Try、Confirm、Cancel の 3 つのメソッドをべき等として実装する必要があります。

2. 空のロールバックの問題

ネットワークの問題により、参加者 (RM) の Try インターフェイス応答がコーディネーター (TM) によって正常に受信されなかった場合、コーディネーター (TM) はキャンセル コマンドを発行します。次に、Cancel インターフェースは Try を実行せずに正常にキャンセルできる必要があります。

3. サスペンションの問題

トランザクション コーディネータが TCC サービスの第 1 フェーズの Try 操作を呼び出すと、ネットワークの輻輳によりタイムアウトが発生する可能性があります。この時点で、トランザクション コーディネータは第 2 フェーズのロールバックをトリガーし、TCC サービスのキャンセル操作を呼び出します。キャンセル呼び出しはタイムアウトしません。その後、ネットワーク上で輻輳した第 1 フェーズの Try データ パケットが TCC サービスによって受信され、第 1 フェーズの Try 要求の前に第 2 フェーズの Cancel 要求が実行されます。遅い Try を実行した後、この TCC サービスは第 2 フェーズの Confirm または Cancel を再度受信しなくなり、TCC サービスがハングすることになります。

したがって、TCC サービスを実装する場合、空のロールバックは許可する必要がありますが、ハングを回避するために、空のロールバック後の Try 要求も拒否する必要があります。

補償されたTCC

上記は、分散トランザクションに関連するすべてのビジネスを制御する必要がある一般的な TCC について説明しています。しかし、場合によっては（たとえば、他社のインターフェースを呼び出すときなど）、一般的な TCC が機能しないことがあります。

したがって、代償的な TCC が存在し、これは Try のない TCC の一種として理解できます。 Try インターフェースが提供されていないため、これは Saga メカニズムの別の形式と見なすことができます。

たとえば、A から B へ、そして B から C へ飛ぶなど、乗り継ぎ便が必要で、乗り継ぎ便が異なる航空会社である場合は、AB と BC の両方のチケットを購入するのが合理的です。

このとき、航空会社のチケット購入操作が直接呼び出されます。両方の航空会社が航空券の購入に成功した場合は、直接成功となります。いずれかの会社がチケットの購入に失敗した場合は、キャンセル予約インターフェイスを呼び出す必要があります。

これは、TCC の第 2 ステージを直接実行するのと同じであり、ロールバック操作には特別な注意が必要です。ロールバックが失敗した場合は、アラームが記録され、手動で介入する必要があります。

要約する

TCC トランザクションは、分散トランザクションをリソース レイヤーからビジネス レイヤーに移動するため、ビジネスはリソース ロックの粒度を柔軟に選択でき、グローバル トランザクションの実行中はロックが常に保持されるわけではないため、システム スループットは 2PC モードよりもはるかに高くなります。

TCC トランザクションによってエンジニアリングの複雑さ、ネットワーク遅延、およびサービス ガバナンスの難しさが増すため、支払いトランザクションに関連するコア ビジネス シナリオ (高い一貫性要件がある) でない限り、TCC トランザクションは他のビジネス シナリオでは使用しないでください。

サガトランザクション

佐賀取引も補償取引です。 TCC の補償と同様に、Try フェーズはありません。代わりに、分散トランザクションは、一連のローカル トランザクションで構成されるトランザクション チェーンとして扱われます。

Saga トランザクションの基本プロトコルは次のとおりです。

• 各 Saga トランザクションは、一連のべき等順序サブトランザクション (参加者として機能するサブトランザクション) Ti で構成されます。

• 各 Ti には対応するべき等補償アクション Ci があり、これは Ti によって発生した結果を元に戻すために使用されます。

取引チェーンに業務シーケンスのロジックが含まれている場合は、取引チェーンの順序を合理的に整理する必要があります（プロジェクトの利益を優先し、漏れがある場合は手動で補充できます。たとえば、出荷前に支払いを差し引く、返金前に商品を返品するなど）。

Saga モデルには準備フェーズがないため、トランザクション間の分離は保証されません。複数の Saga トランザクションが同じリソースに対して動作すると、更新の損失やダーティ データの読み取りなどの問題が発生します。このとき、同時実行性はビジネス レイヤーで制御する必要があります。たとえば、アプリケーション レイヤーでのロックや、アプリケーション レイヤーでのリソースの事前凍結などです。

発注プロセスを例にとると、全体の操作には、在庫の減算 (在庫サービス)、注文の作成 (注文サービス)、支払い (支払いサービス) などが含まれます。

トランザクションは正常に実行され、T1、T2、T3、...、Tn で完了します。たとえば、在庫の減算 (T1)、注文の作成 (T2)、支払い (T3) が順番に実行されます。しかし、決済サービスでエラーが発生します。現時点では、佐賀には 2 つの戦略があります。

Saga トランザクション回復戦略

Saga は 2 つの回復戦略を定義します。

1. フォワードリカバリ

成功が必須であり、失敗した場合に再試行が実行されるシナリオに適用できます。実行順序は次のようになります: T1、T2、...、Tj(失敗)、Tj(再試行)、...、Tn。ここで、j はエラーが発生したサブトランザクションです。

明らかに、フォワードリカバリには必ずしも補償トランザクションは必要ありません。ビジネスにおけるサブトランザクションが（最終的に）成功するか、補償トランザクションを定義するのが困難または不可能な場合は、フォワードリカバリの方がニーズに合致します。

過度に積極的な再試行戦略 (間隔が短すぎる、再試行回数が多すぎるなど) は、下流のサービスに悪影響を及ぼす可能性があるため、より合理的な再試行メカニズムを使用する必要があります。

2. 後退回復

このアプローチの効果は、以前に成功したすべてのサブトランザクションをキャンセルし、Saga 全体の実行結果がキャンセルされることです。

以下に説明する例はすべて後方回復戦略です。

Saga トランザクション調整モード

Saga がトランザクションを実行する順序は、Saga の調整ロジックと呼ばれます。この調整ロジックには、次の 2 つのモード (オーケストレーションとイベント コレオグラフィー) があります。

1. オーケストレーション: Saga は、サブトランザクションの調整を容易にする制御クラスを提供します。トランザクション実行コマンドは制御クラスによって開始され、Saga のサブトランザクションを論理的な順序で要求します。サブトランザクションからのフィードバックを受信した後、制御クラスは他のサブトランザクションへの呼び出しを開始します。 Saga のすべてのサブトランザクションは、この制御クラスを中心に通信および調整を行います。

電子商取引の注文を例に挙げてみましょう。

1. トランザクションイニシエーターの主なビジネスロジックは、コントロールクラスに注文トランザクションを開始するよう要求する。

2. 制御クラスは在庫サービスに在庫を減算するように要求し、在庫サービスは処理結果で応答します。

3. コントロール クラスは注文サービスに注文の作成を要求し、注文サービスは作成結果を返します。

4. 制御クラスは支払いサービスに支払いを要求し、支払いサービスは処理結果で応答します。

5. メインビジネスロジックは、トランザクション結果の応答を受信して​​処理します。

制御クラスは、注文トランザクション全体を実行するために必要なプロセスを事前に認識している必要があります。いずれかが失敗した場合、各サブトランザクションにコマンドを送信して以前の操作を元に戻すことにより、分散ロールバックを調整する責任があります。すべてがコントロール クラスに基づいて調整されている場合、コントロール クラスはデフォルトで順方向のプロセスを実行し、ロールバックするときに逆方向のプロセスを実行するだけで済むため、ロールバックがはるかに簡単になります。

2. イベント コレオグラフィ: サブトランザクションの呼び出し、割り当て、意思決定、および順序付けは、イベントを交換することによって実行されます。これは、サブトランザクションがメッセージ メカニズムを通じて相互に通信し、リスナーを通じて他のサブトランザクションから送信されたメッセージをリッスンして、後続の論理処理を実行する分散モデルです。中間調整ポイントが存在しないため、サブトランザクションは相互に調整されます。

電子商取引の注文を例に挙げてみましょう。

1. トランザクションイニシエーターの主なビジネスロジックは、注文開始イベントを発行します。

2. 在庫サービスは注文開始イベントをリッスンし、在庫を減額し、在庫減額イベントを発行します。

3. 注文サービスは在庫減額イベントをリッスンし、注文を作成し、注文作成イベントを発行します。

4. 支払いサービスは注文作成イベントをリッスンし、支払いを行い、注文支払いイベントを発行します。

5. メインのビジネス ロジックは、注文の支払いイベントを監視および処理します。

実装の比較

コーディネーションベースの Saga の利点は次のとおりです。

1. サービス間の関係は単純で、サブトランザクション間の循環依存関係を回避します。これは、Saga コントロール クラスが Saga サブトランザクションを呼び出しますが、サブトランザクションがコントロール クラスを呼び出さないためです。

2. プログラム開発は簡単です。サブトランザクションは、メッセージの処理方法を考慮せずに独自のタスクを完了するだけでよいため、サブトランザクション アクセスの複雑さが軽減されます。

3. メンテナンスと拡張が簡単です。トランザクションに新しいステップを追加する必要がある場合は、制御クラスを変更するだけで、トランザクションの複雑さを線形に保ち、ロールバックを管理しやすくなります。

4. テストが簡単です。テスト作業は制御クラスに集中し、他のサービスは個別にテストできます。

コーディネーションベースの Saga の欠点は次のとおりです。

1. 制御クラスにロジックを集中させすぎると、保守が困難になるリスクがあります。

2. 制御クラスには単一点障害のリスクがあります。

イベント オーケストレーションに基づく Saga の利点は次のとおりです。

1. 制御における単一点障害のリスクを回避します。

2. サブトランザクションはサブスクリプション時間を通じて相互に通信し、組み合わせの柔軟性を高めます。

イベント オーケストレーションに基づく Saga の欠点は次のとおりです。

1. サービス間の循環依存関係が発生するリスクがあります。

2. 必要なステップが増えると、サービス間の関係がわかりにくくなります。完全なドキュメント サポートがなければ、トランザクション実行プロセス全体を理解するには、コードを読むしかありません。開発者がコードを理解して保守する難易度が増します。

ローカルメッセージテーブルメカニズムに基づく

ローカル メッセージ テーブル メカニズムは、ローカル トランザクション メッセージ テーブルをデータベースに保存し、ローカル トランザクション操作の実行中に操作ステータスをローカル トランザクション メッセージ テーブルに挿入します。メッセージが正常に挿入されると、他のサービスが呼び出されます。呼び出しが成功すると、ローカル メッセージのステータスが変更されます。呼び出しが失敗した場合は、継続的に再試行されます。ダウンストリーム インターフェースでは冪等性を確保する必要があります。

ローカル メッセージ テーブル メカニズムは、ベスト エフォートの通知概念です。

ここでは、支払いサービスと会計サービスを例に、ローカル メッセージ テーブル ソリューションを紹介します。一般的なプロセスは次のとおりです。ユーザーが支払いサービスを通じて支払い注文を正常に完了すると、会計サービス インターフェイスが呼び出され、データベースに元の会計バウチャーが生成されます。全体的なプロセスを図に示します。

プロセスを完了する:

1. 支払いメッセージを記録するために、支払いライブラリにメッセージ テーブルを追加します。つまり、ユーザーが正常に支払いを行うと、支払い成功メッセージが「送信中」のステータスでこのメッセージ テーブルに挿入されます。ここでは、ローカル トランザクションの強力な一貫性を確保する必要があります (支払いロジックとメッセージ テーブルに挿入されたメッセージは、同時に成功するか失敗する強力な一貫性のあるトランザクションを構成します)。

2. ステップ 1 のロジックが完了すると、支払いメッセージが mq の PAY_QUEUE キューに配信されます。この支払いメッセージの内容は、支払いライブラリ メッセージ テーブルに保存されているメッセージの内容と一致しています。

3. 会計サービスはこのメッセージをリッスンし、消費ロジックを処理して会計ドキュメントの生成を開始します。

4. 会計文書が生成されると、消費が成功したことを示すメッセージが ACC_QUEUE キューに返されます。

5. 支払いサービスは、会計サービスによる消費成功のメッセージを監視し、ローカル メッセージ テーブルのメッセージ ステータスを「送信済み」に変更します。

6. メッセージ回復システムは、ステータスが「送信中」のメッセージをローカル メッセージ テーブルから定期的に取得し、MQ の PAY_QUEUE キューに再配信します。

メッセージ回復システムが同じメッセージを一定のしきい値まで再配信すると、アラームが記録され、手動プロセスが通知されます。

要約する

ローカル メッセージ テーブル メカニズムの利点は、構築コストが比較的低いことですが、次の 2 つの欠点もあります。

1. ローカルメッセージテーブルは業務と連動しているため、汎用性を実現することが難しく、独立して運用・管理することができません。

2. ローカル メッセージ テーブルはデータベースに基づいており、同時実行性が高い場合にパフォーマンスのボトルネックが発生します。

トランザクションメッセージメカニズムに基づく

2PC&3PC であっても TCC であっても、ローカル メッセージ トランザクションは基本的に XA プロトコルの考え方に準拠しています。つまり、これらのソリューションは本質的に、さまざまなトランザクション参加者のローカル トランザクションの進行を調整するトランザクション コーディネーターであり、すべてのローカル トランザクションが一緒にコミットまたはロールバックされ、最終的にグローバル実行機能が実現されます。調整プロセス中、コーディネータは各ローカルトランザクションの現在のステータスを収集し、これらのステータスに基づいて次のステージの操作指示を発行する必要があります。

しかし、これらのグローバル トランザクション ソリューションは、操作が面倒であったり、実行に時間がかかったり、グローバル トランザクション中に関連するリソースが排他的にロックされたりするため、分散システム全体のグローバル トランザクションの同時実行性はそれほど高くありません。これにより、電子商取引などの高同時実行シナリオのトランザクション スループット要件を満たすことが困難になるため、インターネット サービス プロバイダーは、XA プロトコルに反する多くの分散トランザクション ソリューションを検討してきました。その中でも、メッセージミドルウェアによって実装される結果的に一貫性のあるグローバルトランザクション（トランザクションメッセージトランザクション）は、古典的なソリューションです。

トランザクションメッセージメカニズムに基づく

通常のメッセージでは、ローカル トランザクションの実行とメッセージ送信の一貫性の問題を解決できません。メッセージ送信はネットワーク通信プロセスであるため、メッセージ送信プロセスが失敗したり、タイムアウトしたりする可能性があります。タイムアウト後、メッセージは正常に送信されるか、失敗する可能性があります。メッセージの送信者を特定できないため、送信者がトランザクションをコミットするかロールバックするかによって不整合が発生する可能性があります。

この問題を解決するには、トランザクション メッセージを導入する必要があります。トランザクション メッセージと通常のメッセージの違いは、トランザクション メッセージが正常に送信された後、準備済み状態になり、サブスクライバーが使用できないことです。ダウンストリーム サブスクライバーは、トランザクション メッセージの状態が消費可能状態に変更された後にのみメッセージを監視できます。

トランザクション メッセージを送信するプロセスは次のとおりです。

1. トランザクション開始者は事前にトランザクション メッセージを送信します。 MQ システムはトランザクション メッセージを受信すると、そのメッセージを永続化し、メッセージのステータスは「送信待ち」となり、送信者に ACK メッセージが送信されます。

2. トランザクション イニシエーターが ACK メッセージを受信しない場合、ローカル トランザクションの実行はキャンセルされます。 ACK メッセージが受信されると、ローカル トランザクションが実行されます。

3. ローカル トランザクションを実行した後、その結果に基づいてコミットまたはロールバック要求が MQ システムに送信されます。

ローカル トランザクションが実行された後、MQ に送信された通知メッセージが失われる可能性があります。したがって、トランザクション メッセージをサポートする MQ システムには、まだ「送信待ち」状態にあるメッセージをスキャンし、メッセージの送信者にクエリを送信してトランザクション メッセージの最終ステータスを問い合わせ、その結果に基づいてトランザクション メッセージのステータスを更新する、時間指定のスキャン ロジックがあります。したがって、トランザクションの開始者は、MQ システムにトランザクション メッセージ ステータス クエリ インターフェイスを提供する必要があります。

4. MQ システムがメッセージ通知を受信した後、リクエストが送信されると、メッセージはサブスクライバーが消費できるように「消費可能」に変更されます。トランザクションがロールバックされると、トランザクション メッセージは削除されます。

トランザクション メッセージのステータスが「送信可能」の場合、MQ システムはメッセージを下流の参加者にプッシュし、プッシュが失敗した場合は継続的に再試行します。

5. メッセージを受信した後、ダウンストリーム参加者はローカル トランザクションを実行します。ローカル トランザクションが正常に実行されると、ACK メッセージが MQ システムに送信されます。実行が失敗した場合、または MQ に送信された ACK メッセージが失われた場合、MQ システムはメッセージをプッシュし続けます。

要約する

最終的な一貫性は、トランザクション メッセージ メカニズムに基づいて実現されます。これは、非同期更新があり、データのリアルタイム要件が高くないシナリオに適しています。

ローカル メッセージ テーブルの実装と比較すると、ローカル メッセージ テーブルを作成したり、ローカル データベース トランザクションに依存したりする必要がないため、このソリューションは同時実行性の高いシナリオに適しています。

RocketMQ は、実稼働環境でのトランザクション ベースのメッセージング メカニズムの使用を直接サポートできます。その他のメッセージング ミドルウェア (Kafka、RabbitMQ など) では、信頼性の高いメッセージング サービスを開発してカプセル化する必要があります。

RocketMQ トランザクション メッセージは、トランザクション制約を満たすためのローカル トランザクション実行とメッセージ送信の問題を解決します。 Kafka トランザクション メッセージは、複数のメッセージを 1 つのトランザクションで送信して、複数のメッセージ間のトランザクション制約を確保する必要がある場合に使用されます。つまり、複数のメッセージが正常に送信されるか、送信に失敗するかのいずれかになります。

ベストエフォート通知メカニズム

ベスト エフォート通知メカニズムの本質は、定期的な検証メカニズムを導入することで最終的な一貫性を保証することです。ビジネスへの介入が少なく、MQ システムに対する要件も低く、実装も比較的簡単です。これは、プラットフォームや企業間のシステム間のビジネス相互作用など、最終的な一貫性と短いビジネス リンクに対する感度が低いシナリオに適しています。

適用可能なシナリオ

シャオミンさんは、中国聯通のオンラインビジネスホールを通じて携帯電話料金をトップチャージしている。全体の操作プロセスは次のとおりです。

1. シャオミンはチャージ金額「50元」と支払い方法「Alipay」を選択します。

2. China Unicom Online Business Hallで「支払中」ステータスの再チャージ注文を作成し、Alipayの支払いページに移動します。

3. Alipayがシャオミンの支払いを検証・確認すると、シャオミンの口座から50元が差し引かれ、China Unicomの口座に50元が追加されます。実行が完了すると、メッセージが MQ システムに送信されます。メッセージの内容は、支払いが成功したかどうかを示します。メッセージ送信の失敗は許可されます。

4. メッセージが正常に送信された場合、Alipay の通知サービスがメッセージを購読し、China Unicom のインターフェースを呼び出してこの支払いの結果を通知します。この時点で China Unicom のサービスが失敗し、通知が失敗した場合、通話が成功するか、事前に設定された時間枠の制限に達するまで、China Unicom のインターフェイスは 5 分、10 分、30 分、1 時間、...、24 時間というように時間間隔を増やして繰り返し呼び出され、通知は行われません。これがベストエフォート通知の意味です。

5. China Unicom のサービスが正常に戻り、Alipay から通知を受け取ったら、アカウントに再チャージしてください (China Unicom の再チャージ インターフェースは冪等性を保証する必要があります)

6. China Unicom のサービス障害が長時間続き、正常に回復した後、Alipay がサービスに通知する時間枠を超えている場合、China Unicom は「支払い」注文をスキャンし、Alipay に注文の支払い結果を確認するリクエストを積極的に開始します。

技術の選択

2PCと3PC

2PC と 3PC はデータベースに大きく依存し、強力な一貫性と強力なトランザクション パフォーマンスを提供できますが、レイテンシは比較的高くなります。これらは、従来の単体アプリケーションに適しています。同じ方法ではデータベース間の操作が行われるため、大規模な分散、高同時実行性、高パフォーマンスのシナリオには適していません。

TCC

TCC は、インターネット金融会社の 3 つのコア サービスである取引、支払い、会計など、実行時間が確実かつ短く、リアルタイム要件が高く、データの一貫性要件が高い状況に適しています。

サガトランザクション

Saga トランザクションは、ビジネス プロセスが長く複数あり、同じリソースに対する同時操作が少ないビジネスに適しています。インターネットマイクロローン、チャネル統合シナリオ、金融機関ドッキングシステム（外部システムとのドッキングが必要）など、銀行や金融機関で広く使用されています。

ローカルメッセージテーブルメカニズムとトランザクションメッセージメカニズムに基づく

どちらも、トランザクション参加者が操作の冪等性をサポートするのに適しており、一貫性の要件が低く、バックアップ メカニズムが最終的な一貫性を達成するまでビジネスにおけるデータの不整合を許容できます。取引にはより少数の当事者とより少ないリンクが関与し、ビジネスは調整/検証システムによってバックアップされます。

ベストエフォート通知メカニズム

ベスト エフォート通知メカニズムは、最終的な一貫性に対する感度が低く、ビジネス リンクが短いシナリオに適しています。

前提条件

本文中に記載されている名詞の追加説明。

DTPモデル

DTP (Distributed Transaction Process) は分散トランザクション モデルです。このモデルには、3 つの役割があります。

1. AP: アプリケーション、トランザクションの開始者、つまりビジネス層。どの操作がトランザクションに属するかは AP によって定義されます。

2. TM: トランザクション マネージャー。コーディネーターとも呼ばれます。 AP からのトランザクション要求の受信、グローバル トランザクションの管理、トランザクション ブランチの状態の管理、RM 処理の調整、どの操作がどのグローバル トランザクションとトランザクション ブランチに属しているかを RM に通知するなど、トランザクション スケジューリング モデル全体の中核部分です。

3. RM: リソース マネージャー (参加者とも呼ばれます)。通常はデータベースですが、メッセージ キュー (JMS データ ソースなど)、ファイル システムなどの他のリソース マネージャーである場合もあります。

DTP モデルでは 3 つのロールが定義されていますが、実際の実装では 1 つのロールが同時に 2 つの機能を実行できます。たとえば、AP と TM を組み合わせると、TM のコンポーネントを個別に展開する必要はありません。

XA仕様

XA は分散トランザクション処理仕様です。 XA は、TM と RM 間の通信インターフェース (下図の機能) を標準化し、TM と複数の RM 間の双方向通信ブリッジを形成して、複数のデータベース リソース下での強力な一貫性を保証します。現在よく知られているデータベース (Oracle、DB2、MySQL など) はすべて XA インターフェイスを実装しており、RM として使用できます。

トランザクション処理プロセス全体を通じて、データは常にロックされた状態になります。つまり、準備からコミット、ロールバックまで、TM は常にデータベース ロックを保持します。他のトランザクションがデータベース内のデータを変更する場合は、ロックが解除されるまで待機する必要があります。