分散トランザクションにおける3つの一般的なソリューション

[[320529]]

1. 分散トランザクションへの序章
2. 柔軟なトランザクションソリューションアーキテクチャ
1. 信頼性の高いメッセージに基づく最終的な一貫性ソリューションの概要
（II）TCC取引補償ソリューション
（III）最善の努力による通知
3. 信頼性の高いメッセージに基づく最終的な一貫性ソリューションの詳細な説明
（I）メッセージ送信の一貫性
（II）メッセージの一貫性を確保するための回避策
（III）従来のMQメッセージ処理フローと特徴
(IV) ビジネスインターフェースのメッセージ繰り返しと冪等性設計
(V) ローカルメッセージサービスソリューション
(VI) 独立メッセージサービスソリューション
(VII) メッセージサービスサブシステムの設計と実装

1. 分散トランザクションへの序章

トランザクション: トランザクションは、一連の操作で構成される信頼性の高い独立した作業単位です。トランザクションには、原子性、一貫性、独立性、永続性という ACID プロパティがあります。

ローカルトランザクション: トランザクションがリソースマネージャーによってローカルに管理される場合、そのトランザクションはローカルトランザクションと呼ばれます。ローカルトランザクションの利点は、厳密な ACID プロパティをサポートし、効率的で信頼性が高く、状態をリソースマネージャー内でのみ維持でき、アプリケーションプログラミングモデルがシンプルであることです。ただし、ローカルトランザクションには分散トランザクションの処理機能がなく、分離の最小単位はリソースマネージャーによって制限されます。

グローバルトランザクション: トランザクションがグローバルトランザクションマネージャーによってグローバルに管理される場合、そのトランザクションはグローバルトランザクションになります。トランザクションマネージャーは、グローバルトランザクションの状態と参加リソースを管理し、リソースの一貫したコミットとロールバックを調整する役割を担います。

TX プロトコル: アプリケーションまたはアプリケーションサーバーとトランザクションマネージャー間のインターフェイス。

XA プロトコル: グローバルトランザクションマネージャーとリソースマネージャー間のインターフェイス。 XA は、X/Open 組織によって提案された分散トランザクション仕様です。この仕様は主に、グローバルトランザクションマネージャーとローカルリソースマネージャー間のインターフェイスを定義します。主流のデータベース製品はすべて XA インターフェースを実装しています。 XA インターフェイスは、トランザクションマネージャーと複数のリソースマネージャー間の通信ブリッジとして機能する双方向システムインターフェイスです。 XA が必要な理由は、分散システムでは理論上 2 台のマシンが一貫した状態に到達できないため、調整のために単一のポイントが導入されるためです。グローバルトランザクションマネージャーによって管理および調整されるトランザクションは、複数のリソースとプロセスにまたがる場合があります。グローバルトランザクションマネージャーは通常、XA 2 フェーズプロトコルを使用してデータベースと対話します。

AP: アプリケーション。DTP (Data Tools Platform) を使用するプログラムとして理解できます。

RM: リソースマネージャー。DBMS またはメッセージサーバー管理システムになります。アプリケーションはリソースマネージャーを通じてリソースを制御し、リソースは XA によって定義されたインターフェイスを実装する必要があります。リソースマネージャーは、実際のリソースの制御と管理を担当します。

TM: トランザクションマネージャー。トランザクションの調整と管理、AP へのプログラミングインターフェイスの提供、リソースマネージャーの管理を担当します。トランザクションマネージャーは、グローバルトランザクションを制御し、トランザクションのライフサイクルを管理し、リソースを調整します。

2 フェーズコミットプロトコル: グローバルトランザクションで複数のリソースを調整するために XA が使用するメカニズム。一貫性の問題を解決するために、TM と RM の間に 2 フェーズコミットソリューションが採用されています。 2 ノード送信では、コーディネーター (TM) がすべての参加ノード (RM) の操作結果を制御し、これらのノードに最終送信を送信するかどうかを指示する必要があります。 2 フェーズコミットの制限は、プロトコルコスト、準備フェーズの永続コスト、グローバルトランザクション状態の永続コスト、複数の潜在的な障害ポイントによって生じる脆弱性、および一連の分離および回復の問題を引き起こす準備後および送信前の障害です。

データ一貫性理論

BASE 理論: BA は、パーティション障害をサポートする基本的なビジネス可用性を指します。 S は柔軟な状態を表し、短期間の同期が許可されることを意味します。 E は最終的な一貫性を意味します。データは最終的には一貫性がありますが、リアルタイムでは一貫性がありません。原子性と耐久性は基本的に保証されなければなりません。可用性、パフォーマンス、およびサービスの低下を防ぐために、一貫性と分離の要件は削減することしかできません。

CAP 定理: 共有データシステムの場合、同時に存在できる CAP は最大 2 つです。いずれの 2 つにも、適用可能なシナリオがそれぞれあります。実際のビジネスシステムは通常、ACID と CAP が混在しています。分散システムで最も重要なことは、高度に抽象化された絶対的なシステム特性を追求するのではなく、ビジネスニーズを満たすことです。 C は一貫性を意味し、すべてのユーザーが同じデータを見ることができることを意味します。 A は可用性を表し、データの利用可能なコピーが常に見つかることを意味します。 P はパーティション耐性を表し、ネットワークの中断などの障害に耐えることができます。

柔軟なトランザクションにおけるサービスモデル

クエリ可能な操作: サービス操作には、グローバルに一意の識別子と、操作の一意で確定的な時間があります。

べき等操作: 繰り返し呼び出しによって生成されるビジネス結果は、単一の呼び出しによって生成される結果と同じです。 1 つ目は、業務処理を通じてべき等性を実現すること、2 つ目は、システムがすべてのリクエストと処理結果をキャッシュし、最後に、重複したリクエストを検出した後、以前の処理結果を自動的に返すことです。

TCC 操作:

試行フェーズ: ビジネス操作を実行し、すべてのビジネスチェックを完了し、一貫性を実現しようとします。準分離を実現するために必要なビジネスリソースを確保します。

確認フェーズ: チェックなしで実際にビジネスを実行します。試行フェーズで予約されたビジネスリソースのみが使用されます。確認操作も冪等性を満たす必要があります。

キャンセルフェーズ: ビジネスの実行をキャンセルし、試行フェーズで予約されたビジネスリソースを解放します。キャンセル操作は冪等性を満たす必要があります。

TCC と 2PC (2 フェーズコミット) プロトコルの違い

TCC は、リソース層ではなくビジネスサービス層に配置されます。 TCC には個別の準備段階はありません。 Try 操作には、リソース操作と準備機能の両方があります。 TCC の Try 操作では、ビジネスリソースを柔軟に選択し、粒度をロックできます。 TCC の開発コストは 2PC よりも高くなります。実際、TCC も 2 段階操作ですが、TCC は 2PC 操作と同等ではありません。

補償可能な操作

実行フェーズ: 業務処理が実際に実行され、業務処理の結果が外部から見えるようになります。

補償フェーズ: 正のビジネス操作のビジネス結果を相殺または部分的にキャンセルし、補償操作は冪等性を満たします。

制約: 補償業務はビジネスの観点から実行可能であり、ビジネス実行結果の分離不足や補償の不完全さによって生じるリスクとコストは制御可能です。

実際、TCC の確認操作とキャンセル操作は補償操作と見なすことができます。

2. 柔軟なトランザクションソリューションアーキテクチャ

電子商取引分野などのインターネットシナリオでは、従来のトランザクションによってデータベースのパフォーマンスと処理機能にボトルネックが生じています。柔軟なトランザクションには、基本的な可用性と柔軟な状態という 2 つの特性があります。いわゆる基本的な可用性とは、分散システムに障害が発生した場合に、ある程度の可用性の損失が許容されることを意味します。柔軟な状態とは、データベースの読み取り/書き込み分離のマスター/スレーブ同期遅延など、システム全体の可用性に影響を与えない中間状態をシステムが持つことが許可されていることを意味します。柔軟なトランザクションの一貫性は、最終的な一貫性を指します。

1. 信頼性の高いメッセージに基づく最終的な一貫性ソリューションの概要

実装: ビジネストランザクションが送信される前に、ビジネス処理サービスはリアルタイムメッセージングサービスにメッセージの送信を要求します。リアルタイムメッセージングサービスでは、メッセージを実際に送信するのではなく、メッセージデータを記録するだけです。ビジネストランザクションが送信されると、ビジネス処理サービスはリアルタイムメッセージングサービスへの送信を確認します。リアルタイムメッセージングサービスは、送信指示の確認を受け取った後にのみ、実際にメッセージを送信します。

メッセージ: ビジネストランザクションがロールバックされた後、ビジネス処理サービスはリアルタイムメッセージングサービスへの送信をキャンセルします。メッセージ送信状態確認システムは、送信またはロールバックが確認できていないメッセージを定期的に検出し、業務処理サービスにメッセージの状態を問い合わせます。ビジネス処理サービスは、メッセージ ID またはメッセージの内容に基づいて、メッセージが有効かどうかを確認します。パッシブ側の処理結果は、アクティブ側の処理結果に影響を与えません。受動側のメッセージ処理操作はべき等操作です。

コスト: 信頼性の高いメッセージシステムを構築するためのコスト。メッセージを送信するには 2 つの要求が必要であり、ビジネス処理サービスではメッセージステータスクエリインターフェイスを実装する必要があります。

利点: メッセージデータは独立して保存および拡張されるため、ビジネスシステムとメッセージシステム間の結合が減少します。最終的な一貫性の時間に非常に敏感であるため、ビジネスの受動的な側面の実装コストが削減されます。 JMS 標準を実装するすべての MQ ミドルウェアと互換性があり、ビジネスデータの信頼性を確保しながらビジネスの究極の一貫性を確保し、理想的には準リアルタイムの一貫性を実現します。

（II）TCC取引補償ソリューション

実装: 完全なビジネスアクティビティは、メインビジネスサービスといくつかの従属ビジネスサービスで構成されます。メインビジネスサービスは、ビジネスアクティビティ全体の開始と完了を担当します。ビジネスサービスからTCC型のビジネスオペレーションを提供します。ビジネスアクティビティマネージャーは、ビジネスアクティビティの一貫性を制御します。ビジネスアクティビティの操作を登録し、ビジネスアクティビティが送信されると、すべての TCC タイプの操作の確認操作を確認します。ビジネスアクティビティがキャンセルされると、すべての TCC タイプ操作のキャンセル操作を呼び出します。

コスト: TCC 操作の実装には、ビジネス活動の終了時に行う確認操作とキャンセル操作の実行コストなど、コストが高くなります。事業活動のコストを記録します。

使用範囲: 強力な分離性と厳格な一貫性要件を備えたビジネス活動。口座処理や手数料の請求など、実行時間が短い業務に適しています。

特徴: 特定のサービスフレームワークと結合されておらず、リソース層ではなくビジネスサービス層に配置されているため、ビジネスリソースのロック粒度を柔軟に選択できます。 TCC では、各サービスリソースはローカルトランザクションで操作されます。データは短時間ロックされ、スケーラビリティに優れています。独立して展開される SOA サービス向けに設計されていると言えます。

（III）最善の努力による通知

実装: ビジネスアクティビティのアクティブ側は、処理を完了した後、ビジネスアクティビティのパッシブ側にメッセージを送信し、メッセージが失われることがあります。ビジネスアクティビティの受動的な側は、タイミング戦略に従ってビジネスアクティビティの能動的な側に問い合わせて、失われたビジネスメッセージを回復します。

制約: パッシブ側の処理結果は、アクティブ側の処理結果に影響を与えません。

コスト: ビジネスクエリおよび校正システムの構築にかかるコスト。

適用範囲: ビジネスの最終的な一貫性に対する時間的感度が低い。企業間をまたいだビジネス活動。

機能: ビジネス処理が完了すると、ビジネスアクティビティのアクティブパーティは、ビジネスアクティビティのパッシブパーティに通知メッセージを送信します。アクティブなパーティは、時間階層化された通知ルールを設定し、通知が失敗した後にルールに従って通知を繰り返すことができます。 N 回の通知の後は、それ以上の通知は行われません。アクティブ側は、オンデマンド校正クエリ用の校正クエリインターフェイスをパッシブ側に提供し、ユーザーが失われたビジネスメッセージを回復できるようにします。

適用範囲：銀行通知、加盟店通知。

3. 信頼性の高いメッセージに基づく最終的な一貫性ソリューションの詳細な説明

（I）メッセージ送信の一貫性

分散システムにおけるメッセージミドルウェアの中心的な役割は、非同期通信、アプリケーションの分離、および同時バッファリング (トラフィックピークシェービングとも呼ばれます) です。分散環境では、ネットワークを介して通信を実行する必要があり、データ転送に不確実性が生じます。これが CAP 理論におけるパーティションフォールトトレランスです。

メッセージ送信の一貫性とは、メッセージを生成するビジネスアクションがメッセージの送信と一貫していることを意味します。つまり、ビジネス操作が成功した場合、このビジネス操作によって生成されたメッセージは送信される必要があり、そうでない場合は失われます。

処理方法1

パブリックvoid completeOrderService() {
  // 注文を処理する
注文.process();
  //会計元の伝票メッセージを送信する
  パイプ.sendAccountingVouchetMessage();
 }

上記の状況では、業務処理が成功した場合、実行されたメッセージが送信される前にアプリケーションが失敗し、メッセージが送信できず、メッセージが失われ、受注システムと会計システム間でデータの不整合が発生します。メッセージシステムやネットワークに異常がある場合、メッセージを送信できず、データの不整合が発生する可能性があります。

解決策2

パブリックvoid completeOrderService() {
  //会計元の伝票メッセージを送信する
  パイプ.sendAccountingVouchetMessage();
  // 注文を処理する
注文.process();
 }

上記の 2 つの操作の順序が逆になると、状況はさらに制御不能になります。メッセージの送信後に業務注文が失敗し、注文システムと業務システム間でデータの不整合が発生する可能性があります。では、JMS 標準の XA プロトコルは送信の一貫性を保証できるのでしょうか?

JMS プロトコル標準 API には、XA で始まる多くのインターフェイスがありますが、これらは実際には、前述の XA プロトコル (2 フェーズコミットプロトコルに基づく) をサポートするグローバルトランザクションインターフェイスです。

 XAConnection.クラス
XAConnectionFactory.クラス
XAQueueConnection.クラス
XAQueueConnectionFactory.クラス
XASession.クラス
XATopicConnection.クラス
XATopicConnectionFactory.クラス
XATopicSession.クラス

JMS の XA シリーズのインターフェースは、分散トランザクションのサポートを提供できます。ただし、XA 分散トランザクションを使用すると、多くの制限が生じます。

ビジネスオペレーションに必要なリソースは XA プロトコルをサポートする必要がありますが、すべてのリソースが XA プロトコルをサポートしているわけではありません。

2 フェーズコミットプロトコルのコスト。

グローバルロックなどの永続コスト、高コスト、低パフォーマンスなどの DTP モデルの制限。

XA プロトコルの使用は、柔軟なトランザクションの本来の目的に反します。

（II）メッセージの一貫性を確保するための回避策

メッセージの送信: アクティブなパーティがアプリケーションを通じてメッセージをメッセージミドルウェアに送信し、メッセージのステータスが「確認待ち」としてマークされます。

メッセージミドルウェアは、メッセージを受信した後、メッセージをメッセージストレージに保存しますが、受動側のメッセージ配信には影響しません。

メッセージミドルウェアはメッセージの永続化結果を返し、アクティブパーティは返された結果に基づいてビジネス操作を実行する方法を決定します。

失敗: 業務処理を放棄して終了し、必要に応じて処理結果を上位層に返します。

成功: ビジネス操作処理を実行します。

ビジネス操作が完了すると、ビジネス操作の結果がメッセージミドルウェアに返されます。

メッセージミドルウェアは、ビジネス操作構造を受信すると、ビジネス結果に応じてそれを処理します。

失敗: メッセージストアからメッセージを削除しています。終了しています。

成功: メッセージストレージ内のメッセージステータスを「保留中」に更新し、メッセージ配信を実行します。

前の肯定的なプロセスが成功すると、メッセージはパッシブアプリケーションに配信されます。

ただし、上記の処理フローでは、どのリンクでも問題が発生する可能性があります。

（III）従来のMQメッセージ処理フローと特徴

従来の MQ キュー処理ではメッセージの一貫性を実現できません。

メッセージ配信の本質はメッセージの消費であり、これは洗練することができます。

(IV) ビジネスインターフェースのメッセージ繰り返しと冪等性設計

未確認メッセージは、ルールに従って再配信することによって処理されます。上記のプロセスでは、メッセージを繰り返し送信すると、ビジネス処理インターフェイスが繰り返し呼び出されます。メッセージ消費プロセス中にメッセージが繰り返し送信される主な理由は、コンシューマーがメッセージを正常に受信して処理した後、メッセージミドルウェアが配信ステータスを時間内に更新しないことです。メッセージを繰り返し送信することが許可されている場合、コンシューマーはビジネスインターフェイスのべき等設計を実装する必要があります。

(V) ローカルメッセージサービスソリューション

実装のアイデア:

アクティブアプリケーションシステムは、業務オペレーションを通じて業務データの操作を完了します。メッセージを送信する準備をするとき、メッセージのコピーの 1 つをアクティブアプリケーションシステムに保存し、別のコピーをリアルタイムメッセージングサービスに送信します。

パッシブアプリケーションシステムは、リアルタイムメッセージングシステム内のメッセージを監視します。パッシブアプリケーションがメッセージ処理を完了すると、アクティブアプリケーションインターフェイスを呼び出してメッセージ確認を完了します。

アクティブ側はメッセージの確認を受け取った後、メッセージデータを削除します。

メッセージクエリサービスが、メッセージを受信してから指定された時間内に ACK 確認メッセージが返されないことを検出した場合、メッセージ回復システムはメッセージを再送信します。

アドバンテージ：

メッセージの適時性は比較的高い

アプリケーション設計の観点から、メッセージデータの信頼性が実現されます。メッセージデータの信頼性は MQ ミドルウェアに依存しないため、MQ ミドルウェアの特性への依存が弱まります。

このソリューションは軽量で実装が簡単です。

欠点:

特定のビジネスシナリオにバインドされ、強い結合があり、共有できません。

メッセージデータはビジネスデータと同期され、ビジネスシステムのリソースを占有します。

ビジネスシステムでリレーショナルデータベースを使用する場合、メッセージサービスのパフォーマンスはリレーショナルデータベースの同時実行パフォーマンスによって制限されます。

(VI) 独立メッセージサービスソリューション

実装のアイデア:

事前送信メッセージ: アクティブアプリケーションシステムはメッセージを事前送信し、そのメッセージはメッセージサービスサブシステムによって保存されます。ストレージに障害が発生すると、業務を遂行できなくなります。返却保管が成功したら業務操作を実行します。

ビジネスオペレーションの実行: ビジネスオペレーションが正常に実行された場合、ビジネスオペレーションの正常な実行のステータスがメッセージサービスサブシステムに送信されます。メッセージサービスサブシステムは、メッセージフラグを「送信可能」状態に変更します。

リアルタイムメッセージングサービスにメッセージを送信: メッセージのステータスが変更されると、メッセージはすぐにリアルタイムメッセージングサービスに送信されます。次に、メッセージはメッセージサービスのコンシューマーによって監視され、消費されます。

メッセージステータスサブシステム: スケジュールされたタスクシステムに相当します。メッセージサービスサブシステム内でタイムアウトが確認されたメッセージを定期的に検索し、また、アクティブなアプリケーションシステム内で正常に処理されなかったタスクを定期的に検索し、対応する処理を実行します。

メッセージの消費: メッセージが消費されると、ACK がリアルタイムメッセージングサービスに送信され、その後、リアルタイムメッセージングサービスによってメッセージが削除されます。同時に、メッセージサービスサブシステムが呼び出され、メッセージが「消費済み」状態に変更されます。

メッセージ回復サブシステム: コンシューマーがメッセージを返すときに、ネットワークの中断やその他の理由によりメッセージが時間内に確認されない場合、メッセージ回復サブシステムは、メッセージサービスサブシステムで確認されていないメッセージを定期的に見つける必要があります。パッシブアプリケーションシステムのインターフェイスはべき等であるため、未確認メッセージをリアルタイムメッセージングサービスに入れてやり直します。

アドバンテージ：

メッセージサービスは独立して展開、保守、拡張されます。

メッセージストレージは、必要に応じてさまざまなデータベースと統合できます。

メッセージサービスは同じ使用シナリオで使用できるため、重複するサービスを構築するコストが削減されます。

分散サービスアプリケーションの設計と開発の観点から、メッセージデータの信頼性が実現されます。メッセージデータの信頼性は MQ ミドルウェアに依存しないため、MQ ミドルウェアの特性への依存が弱まります。

ビジネスシステムとメッセージシステム間の結合が軽減され、システムの拡張と保守に役立ちます。

欠点:

メッセージを送信するには 2 つのリクエストが必要です。

アクティブアプリケーションシステムでは、業務運用状況の検証および照会インターフェースを実装する必要があります。

(VII) メッセージサービスサブシステムの設計と実装

サンプルメッセージデータテーブル:

<<: Kafka はなぜこんなに速いのでしょうか?