3つの主流の分散トランザクションソリューションの長所と短所の詳細な説明

[[281095]]

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

3)TCC操作：

• 試行フェーズ: ビジネス操作を実行し、すべてのビジネス チェックを完了し、一貫性を実現しようとします。準分離を実現するために必要なビジネスリソースを確保します。
• 確認フェーズ: チェックなしで実際に業務を実行します。試行フェーズで予約されたビジネス リソースのみが使用されます。確認操作も冪等性を満たす必要があります。
• キャンセル フェーズ: ビジネスの実行をキャンセルし、試行フェーズで予約されたビジネス リソースを解放します。キャンセル操作は冪等性を満たす必要があります。

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

4) 補償可能な操作:

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

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

制約: 補償業務はビジネスの観点から実行可能であり、ビジネス実行結果の分離不足や補償の不完全さによって生じるリスクとコストは制御可能です。実際、TCC の確認操作とキャンセル操作は補償操作と見なすことができます。

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

電子商取引分野などのインターネット シナリオでは、従来のトランザクションによってデータベースのパフォーマンスと処理機能にボトルネックが生じています。柔軟なトランザクションには、基本的な可用性と柔軟な状態という 2 つの特性があります。

いわゆる基本的な可用性とは、分散システムに障害が発生した場合に、ある程度の可用性の損失が許容されることを意味します。柔軟な状態とは、データベースの読み取り/書き込み分離のマスター/スレーブ同期遅延など、システム全体の可用性に影響を与えない中間状態をシステムが持つことが許可されていることを意味します。柔軟なトランザクションの一貫性は、最終的な一貫性を指します。

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

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

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

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

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

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

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

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

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

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

ベストエフォート通知

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

2) 制約: 受動的なパーティの処理結果は、能動的なパーティの処理結果に影響を与えません。

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

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

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

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

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

メッセージ送信の一貫性

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

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

解決策1:

パブリックvoid completeOrderService { 
 
 // 注文を処理する
 
注文処理; 
 
 //会計元の伝票メッセージを送信する
 
パイプ.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 プロトコルの使用は、柔軟なトランザクションの本来の目的に反します。

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

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

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

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

• 失敗: 業務処理を中止し、終了し、必要に応じて処理結果を上位層に返します。
• 成功: ビジネス操作処理を実行します。

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

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

前の肯定的なプロセスが成功すると、メッセージはパッシブ アプリケーションに配信されます。ただし、上記の処理フローでは、どのリンクでも問題が発生する可能性があります。

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

従来の MQ キュー処理ではメッセージの一貫性を実現できません。メッセージ配信の本質はメッセージの消費であり、これは洗練することができます。

メッセージ重複問題とビジネスインターフェースの冪等性設計

未確認メッセージは、ルールに従って再配信することによって処理されます。上記のプロセスでは、メッセージを繰り返し送信すると、ビジネス処理インターフェイスが繰り返し呼び出されます。

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

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

1) 実装のアイデア:

• アクティブアプリケーションシステムは、業務オペレーションを通じて業務データの操作を完了します。メッセージを送信する準備をするとき、メッセージのコピーの 1 つをアクティブ アプリケーション システムに保存し、別のコピーをリアルタイム メッセージング サービスに送信します。
• パッシブ アプリケーション システムは、リアルタイム メッセージング システム内のメッセージを監視します。パッシブ アプリケーションがメッセージ処理を完了すると、アクティブ アプリケーション インターフェイスを呼び出してメッセージ確認を完了します。
• アクティブパーティはメッセージの確認を受け取った後、メッセージデータを削除します。
• メッセージ クエリ サービスが、メッセージを受信して​​から指定された時間内に ACK 確認メッセージが返されないことを検出した場合、メッセージ回復システムはメッセージを再送信します。

2) 利点:

• メッセージの適時性は比較的高いです。
• アプリケーション設計の観点から、メッセージ データの信頼性が実現されます。メッセージ データの信頼性は MQ ミドルウェアに依存しないため、MQ ミドルウェアの特性への依存が弱まります。
• このソリューションは軽量で実装が簡単です。

3) デメリット:

• 特定のビジネス シナリオにバインドされ、強い結合があり、共有できません。
• メッセージ データはビジネス データと同期され、ビジネス システムのリソースを占有します。
• ビジネス システムでリレーショナル データベースを使用する場合、メッセージ サービスのパフォーマンスはリレーショナル データベースの同時実行パフォーマンスによって制限されます。

独立したメッセージングサービスソリューション

1) 実装のアイデア:

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

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

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

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

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

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

2) 利点:

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

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

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

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

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

3) デメリット:

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

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

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

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