分散トランザクションを実装するにはどうすればいいですか? Seata の XA モデルの詳細な分析

Seata 1.2.0 バージョンでは、XA プロトコルをサポートする新しいトランザクションモードである XA モードがリリースされました。

[[324167]]

ここでは、この新機能を次の 3 つの側面から詳しく解説します。

概要: XA パターンとは何ですか?
理由: XA をサポートする理由は何ですか?
方法: XA パターンはどのように実装され、どのように使用できますか?

1. XA モードとは何ですか?

ここでは 2 つの基本的な前提条件があります。

XAとは何ですか?
Seata によって定義されるいわゆるトランザクションモードとは何ですか?

これら 2 つの点を踏まえると、XA モードを理解するのは自然なことです。

1.1 XA とは何ですか?

XA 仕様は、X/Open 組織によって定義された分散トランザクション処理 (DTP) 標準です。

XA 仕様は、グローバルトランザクションマネージャーとローカルリソースマネージャー間のインターフェイスについて記述します。 XA 仕様の目的は、ACID プロパティがアプリケーション間で有効なままになるように、同じトランザクションで複数のリソース (データベース、アプリケーションサーバー、メッセージキューなど) にアクセスできるようにすることです。

XA 仕様では、2 フェーズコミット (2PC) を使用して、すべてのリソースが特定のトランザクションを同時にコミットまたはロールバックすることを保証します。

XA 仕様は 1990 年代初頭に提案されました。現在、ほとんどすべての主流データベースが XA 仕様をサポートしています。

1.2 Seata のトランザクションモードとは何ですか?

Seata はグローバルトランザクションのフレームワークを定義します。

グローバルトランザクションは、複数のブランチトランザクションの全体的な調整として定義されます。

TM は、TC にグローバルトランザクションの開始 (Begin)、コミット (Commit)、およびロールバック (Rollback) を要求します。
TM は、グローバルトランザクションを表す XID をブランチトランザクションにバインドします。
RM は TC に登録し、ブランチトランザクションを XID によって表されるグローバルトランザクションに関連付けます。
RM は分岐トランザクションの実行結果を TC に報告します。（オプション）
TC は、ブランチコミット (Branch Commit) またはブランチロールバック (Branch Rollback) コマンドを RM に送信します。

Seata のグローバルトランザクション処理プロセスは、次の 2 つの段階に分かれています。

実行フェーズ: ブランチトランザクションを実行し、実行結果がロールバック可能で永続的であることを確認します。
完了フェーズ: 実行フェーズで行われた決定に基づいて、アプリケーションは TM を介して TC にグローバルコミットまたはロールバック要求を送信し、TC は RM にブランチトランザクションをコミットまたはロールバックするように指示します。

Seata のいわゆるトランザクションモードは、Seata グローバルトランザクションフレームワークの下で実行されるブランチトランザクションの動作モードを指します。正確には、ブランチトランザクションモードと呼ぶべきでしょう。

異なるトランザクションモード間の違いは、ブランチトランザクションでは、グローバルトランザクションの 2 つのステージの目標を達成するために異なる方法を使用することです。つまり、次の 2 つの質問に答えます。

実行フェーズ: 実行方法と、実行結果がロールバック可能で永続的であることを確認する方法。
完了段階: TC からコマンドを受信した後、ブランチをコミットまたはロールバックするにはどうすればよいですか?

理解するために、Seata の AT モードと TCC モードを例に挙げてみましょう。

ATモード

実行フェーズ:

ロールバック: SQL解析結果に基づいてロールバックログを記録する
永続性: ロールバックログとビジネスSQLは同じローカルトランザクションでデータベースにコミットされます。

完了段階:

ブランチコミット: ロールバックログレコードを非同期的に削除する
ブランチロールバック: ロールバックログに基づく逆補償更新

TCC モード

実行フェーズ:

ビジネスで定義されたTryメソッドを呼び出す（ロールバックと永続性はビジネス層によって完全に保証されます）

完了段階:

ブランチコミット: 各トランザクションブランチで定義されたConfirmメソッドを呼び出す
ブランチロールバック: 各トランザクションブランチで定義されたCancelメソッドを呼び出す

1.3 Seata の XA モードとは何ですか?

XA モード:

Seata で定義された分散トランザクションフレームワークでは、XA プロトコルのトランザクションリソース (データベース、メッセージサービスなど) のサポートと XA プロトコルのメカニズムを使用して、トランザクションモードを使用してブランチトランザクションを管理します。

実行フェーズ:

ロールバック: ビジネス SQL 操作は XA ブランチで実行され、ロールバックは XA プロトコルのリソースサポートによって保証されます。
永続性: XA ブランチが完了すると、XA 準備が実行されます。同様に、リソースの XA プロトコルのサポートにより永続性が保証されます (つまり、その後の事故によってロールバックが不可能になる状況は発生しません)。

完了段階:

ブランチコミット: XAブランチのコミットを実行する
ブランチロールバック: XAブランチのロールバックを実行します

2. XA をサポートする理由は何ですか?

Seata に XA モードを追加する理由は何ですか? XA をサポートすることの意義は何ですか?

2.1 補償取引パターンの問題点

本質的には、Seata がすでにサポートしている 3 つの主要なトランザクションモード (AT、TCC、Saga) はすべて補償的です。

補正トランザクション処理メカニズムはトランザクションリソース (ミドルウェアレベルまたはアプリケーションレベル) 上に構築され、トランザクションリソース自体は分散トランザクションを認識しません。

トランザクションリソースが分散トランザクションを認識しない場合、真のグローバル一貫性を実現できないという根本的な問題があります。

たとえば、在庫レコードがトランザクションの補正処理中に 100 から 50 に減算されたとします。この時点で、倉庫管理者はデータベースに接続し、在庫統計を照会して、現在の数値が 50 であることを確認します。その後、例外によりトランザクションがロールバックされ、在庫は 100 にロールバックされます。明らかに、倉庫管理者がカウントした 50 はダーティデータです。

補償分散トランザクションメカニズムは、トランザクションリソース自体のメカニズム (データベースなど) の参加を必要としないため、トランザクションフレームワーク外部のグローバルな観点からデータの一貫性を保証することはできないことがわかります。

2.2 XAの価値

補正タイプとは異なり、XA プロトコルでは、仕様とプロトコルのサポートを提供するためにトランザクションリソース自体が必要になります。

トランザクションリソースは分散トランザクション処理プロセスを認識して参加するため、トランザクションリソース (データベースなど) はあらゆる観点からデータアクセスの効果的な分離を保証し、グローバルなデータ一貫性を満たすことができます。

たとえば、前のセクションで説明した在庫更新シナリオでは、XA トランザクション処理中に、中間データ在庫 50 はデータベース自体によって保証され、ウェアハウス管理者のクエリ統計には表示されません。 (もちろん、分離レベルは読み取りコミット以上である必要があります)

グローバルな一貫性の基本的な価値に加えて、XA をサポートすると次の利点があります。

ビジネスに支障をきたさない: AT と同様に、XA モードはビジネスに支障をきたさず、アプリケーションの設計や開発に追加の負担をかけることはありません。
幅広いデータベースサポート: XA プロトコルは、主流のリレーショナルデータベースで広くサポートされており、追加の調整なしで使用できます。
容易な多言語サポート：XA モードでは SQL 解析が不要なため、Seata の RM に対する要件が少なく、異なる言語向けの SDK の開発も AT モードよりも軽量かつ容易になります。
従来の XA ベースアプリケーションの移行: XA モードを使用すると、従来の XA ベースアプリケーションを Seata プラットフォームに移行する作業がよりスムーズになります。

2.3 XA の広く疑問視されている問題

すべてのシナリオに完全に適応し、すべてのニーズを満たすことができる分散トランザクションメカニズムは存在しません。

XA 仕様は、分散トランザクション処理の分野における問題を解決するために、1990 年代初頭に提案されました。

さて、AT モード、TCC モード、Saga モードのいずれであっても、これらのモードが提案されるのは、基本的に、XA 仕様が特定のシナリオの要件を満たすことができないためです。

XA 仕様で定義されている分散トランザクション処理メカニズムには、広く疑問視されている問題がいくつかあります。これらの問題について私たちはどう考えますか?

1. データロック: トランザクションプロセス全体の終了前にデータがロックされ、分離レベルの定義に従って読み取りと書き込みが制限されます。

考える：

データロックは、より高い分離性とグローバルな一貫性を実現するための代償です。

補償トランザクション処理メカニズムは、実行フェーズ中にブランチ (ローカル) トランザクションの送信を完了し、データをロックしません (リソースレベル)。これは孤立を犠牲にして実現します。

また、AT モードでは、基本的な書き込み分離を確保するためにグローバルロックが使用され、実際にデータがロックされますが、ロックは TC 側で集中管理されるため、ロック解除効率が高く、ブロッキングの問題は発生しません。

2. プロトコルブロッキング: XA 準備後、ブランチトランザクションはブロッキングフェーズに入り、XA コミットまたは XA ロールバックが受信されるまで待機する必要があります。

考える：

プロトコル自体のブロッキングメカニズムは問題ではありません。主な問題は、データロックに遭遇したプロトコルブロッキングにあります。

グローバルトランザクションに参加しているリソースが「失われた」(ブランチトランザクションを終了するコマンドを受信しなかった) 場合、そのリソースがロックしているデータはロックされたままになります。さらに、その結果デッドロックが発生する可能性もあります。

これは XA プロトコルの中心的な問題点であり、Seata が XA モデルを導入する際に解決したい重要な問題でもあります。

基本的な考え方は 2 つあります。「接続の喪失」を回避することと、「自動ロック解除」メカニズムを追加することです。 (これには多くの技術的な詳細が含まれますが、当面は詳しく説明しません。XA モードの今後の進化のときに具体的に説明します。)

3. パフォーマンスの低下: パフォーマンスの低下は主に 2 つの側面から生じます。一方では、トランザクション調整プロセスによって単一トランザクションの RT が増加します。一方、同時トランザクションデータのロック競合によりスループットが低下します。

考える：

分散トランザクションをサポートしない実行シナリオと比較すると、パフォーマンスは確実に低下します。その点については疑いの余地はありません。

本質的には、トランザクションメカニズム (ローカルか分散かに関係なく) は、単純なプログラミングモデルと引き換えに、ある程度のパフォーマンスを犠牲にします。

非侵入型 AT モードとの比較:

まず、Seata によって定義された分散トランザクションフレームワークの下でも実行されるため、XA モードではトランザクション調整のための通信オーバーヘッドがさらに発生しません。

次に、同時実行トランザクション間のデータにホットスポットがある場合、ロックの競合が発生します。この状況は AT モードでも発生します (デフォルトではグローバルロックが使用されます)。

したがって、パフォーマンスに影響を与える 2 つの主な側面において、XA モードは AT モードに比べてそれほど明らかな欠点はありません。

AT モードのパフォーマンス上の利点は、主に、グローバルデータロックの集中管理、ロック解除に RM の参加が不要、ロック解除が非常に高速であることです。さらに、グローバルに送信されたトランザクションの完了段階は非同期です。

3. XA モードを実装して使用する方法は?

3.1 XAモードの設計

3.1.1 設計目標

XA モードの基本的な設計目標は、主に次の 2 つの側面です。

シナリオの観点から見ると、グローバルな一貫性のニーズを満たしています。
アプリケーション面では、AT モードと同じ非侵入性を維持します。
メカニズムの観点から見ると、分散型マイクロサービスアーキテクチャの特性に適応します。

全体的なアイデア:

AT モードと同じです。アプリケーション内のローカルトランザクションの粒度で、XA モードにブランチトランザクションを構築します。

データソースプロキシを通じて、XA プロトコルの相互作用メカニズムがアプリケーションのローカルトランザクションの範囲外のフレームワークレベルでパッケージ化され、XA プログラミングモデルが透過的になります。

XA の 2PC を分離し、分岐トランザクション実行フェーズの最後に XA 準備を実行し、XA プロトコルを Seata のトランザクションフレームワークに完全に統合し、RPC 対話の 1 ラウンドを削減します。

3.1.2 コア設計

1. 全体的な動作メカニズム

XA モードは、Seata によって定義されたトランザクションフレームワーク内で実行されます。

実行フェーズ:

XA 開始/XA 終了/XA 準備 + SQL + 登録ブランチ

仕上げ段階:

XA コミット/XA ロールバック

2. データソースエージェント

XA モードには XAConnection が必要です。

XAConnection を取得するには 2 つの方法があります。

方法 1: 開発者に XADataSource の設定を要求する
方法2: 開発者の共通データソースに基づいて作成する

最初のアプローチでは、開発者に認知的負担が追加されます。開発者は、XA モード専用の XA データソースを学習して使用する必要があるため、透過的な XA プログラミングモデルの設計目標に反します。

2 番目の方法は開発者にとってより使いやすいです。 AT モードと同様に、開発者は XA レベルの問題を心配する必要がなく、ローカルプログラミングモデルを維持するだけで済みます。

2 番目の方法の設計と実装を優先します。データソースプロキシは、通常のデータソースから取得した通常の JDBC 接続に基づいて、対応する XAConnection を作成します。

AT モードのデータソースプロキシメカニズムに類似しており、次のようになります。

ただし、2 番目の方法には制限があり、互換性の正確さを保証できません。

実際には、このアプローチはデータベースドライバーが実行すべきことを実行します。異なるメーカーおよび異なるバージョンのデータベースドライバー実装メカニズムは、メーカー独自のものです。完全にテストされたドライバー上で正しいことのみを保証できます。開発者が使用するドライバーのバージョンの違いにより、メカニズムが失敗する可能性があります。

これは Oracle では非常に明白です。 Druid の問題を参照してください: https://github.com/alibaba/druid/issues/3707

すべての要素を考慮すると、XA モードのデータソースプロキシの設計では、最初の方法、つまり XA データソースに基づくプロキシをサポートする必要があります。

AT モードのデータソースプロキシメカニズムに類似しており、次のようになります。

3. 支店登録

XA の開始には Xid パラメータが必要です。

この Xid は、TC が XA ブランチのコミットまたはロールバックを実行できるように、Seata グローバルトランザクションの XID および BranchId に関連付ける必要があります。

現在、Seata の BranchId はブランチ登録プロセス中に TC によって均一に生成されるため、XA モードのブランチ登録のタイミングは XA の開始前である必要があります。

将来的に考えられる最適化の方向性:

ブランチ登録は可能な限り延期してください。 AT モードと同様に、ブランチはローカルトランザクションがコミットされる前に登録されるため、ブランチ実行が失敗した場合に意味のないブランチ登録が回避されます。

この最適化の方向では、BranchId 生成メカニズムの変更が必要になります。 BranchId はブランチ登録プロセスを通じて生成されるのではなく、生成されてから BranchId を使用してブランチを登録するために使用されます。

まとめ

ここでは、XA モードの基本的な動作メカニズムを説明するために、いくつかの重要なコア設計のみを使用します。

さらに、接続の維持や例外処理などの重要な側面もあります。興味があれば、プロジェクトコードから詳細を確認できます。

それを書き留めて、将来皆さんと共有したいと思います。

3.1.3 進化計画

XA モードの全体的な進化計画は次のとおりです。

ステップ 1 (完了): 最初のバージョン (1.2.0) では、XA モードのプロトタイプメカニズムが実行されました。追加のみを行い、変更は行わず、他のモードに新しい問題が発生しないようにしてください。

ステップ 2 (5 月に完了予定): AT モデルとの必要な統合と再構築。

ステップ3（7月完了予定）：例外処理の仕組みを改善し、本番稼働に必要な仕上げを行います。

ステップ 4 (8 月に完了予定): パフォーマンスの最適化。

ステップ 5 (2020 年に完了予定): Seata プロジェクトの進行中のクラウドネイティブトランザクションメッシュ設計を組み合わせて、クラウドネイティブ機能を構築します。

3.2 XAモードの使用

プログラミングモデルから見ると、XA モードは AT モードと完全に一致しています。

Seataの公式サイトの例を参照できます: seata-xa

サンプルシナリオは、在庫、注文、アカウントの 3 つのマイクロサービスを含む従来の Seata 製品注文ビジネスです。

サンプルでは、上位レベルのプログラミングモデルは AT モードのものとまったく同じです。 XA モードと AT モードを切り替えるには、データソースプロキシを変更するだけで済みます。

 @Bean( "データソースプロキシ" )
パブリックデータソースデータソース(DruidDataSource druidDataSource) {
       // DataSourceProxyの  ATモード
       //新しい DataSourceProxy(druidDataSource)を返します。 
 
       // XA モードのDataSourceProxyXA
新しい DataSourceProxyXA(druidDataSource)を返します。
   }

4. 結論

技術開発の現段階では、あらゆるシナリオのニーズに完全に応えられる分散トランザクション処理メカニズムは存在しません。

一貫性、信頼性、使いやすさ、パフォーマンスなど、さまざまな側面におけるシステム設計の制約は、さまざまなトランザクション処理メカニズムによって満たす必要があります。

Seata プロジェクトの核となる価値は、分散トランザクションの問題を包括的に解決する標準化されたプラットフォームを構築することにあります。

Seata をベースにした上位レベルのアプリケーションアーキテクチャでは、実際のシナリオのニーズに応じて適切な分散トランザクションソリューションを柔軟に選択できます。

XA モードの追加により、グローバル一貫性シナリオにおける Seata のギャップが埋められ、AT、TCC、Saga、XA という 4 つの主要なトランザクションモードのマップが形成され、基本的にすべてのシナリオの分散トランザクション処理要件を満たすことができます。

もちろん、XA モデルや Seata プロジェクト自体はまだ完璧ではなく、改善して完成させる必要がある領域は数多くあります。誰でもプロジェクト構築に参加し、標準化された分散トランザクションプラットフォームを共同で作成できます。

著者について: Xuan Yu (GitHub ID: sharajava) は、Alibaba Middleware の GTS R&D チームの責任者であり、SEATA オープンソースプロジェクトの創始者です。彼は長年にわたり Oracle 北京 R&D センターに勤務し、WebLogic コアの R&D に従事しました。ミドルウェア、特に分散トランザクションの分野における技術実践に長期的に注力します。

この記事はWeChatの公開アカウント「高可用性アーキテクチャ」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、High Availability Architecture のパブリックアカウントにお問い合わせください。

<<: プライベートクラウドからパブリッククラウドの消費モデルに移行する方法

>>: 分散データキャッシュ技術、その謎を解明