Seata 分散トランザクション XA および AT の総合分析

[[395191]]

Seata は、19,200 を超えるスターと非常に活発なコミュニティを持つオープンソースの分散トランザクション ソリューションです。マイクロサービス アーキテクチャに基づいて、高性能で使いやすい分散トランザクション サービスを提供することに取り組んでいます。

目次

• XA モードとは何ですか?
• Seata の取引モードは何ですか?
• ATモードとは何ですか？
• Seata が XA モードをサポートするのはなぜですか?
• ATとXAの関係
• 要約する

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

まず、Xuanyu兄さんがおっしゃったように、XAとは何か、Seataで定義されているトランザクションモードが何であるかを理解すれば一目瞭然です。

1.1 XAとは何か

非常に公式な言葉で言えば

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

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

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

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

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

Seata はグローバル トランザクションのフレームワークを定義します。グローバル トランザクションは、複数のブランチ トランザクションの全体的な調整として定義されます。1. TM は、TC にグローバル トランザクションの開始 (Begin)、コミット (Commit)、またはロールバック (Rollback) を要求します。 2.TM は、グローバル トランザクションを表す XID をブランチ トランザクションにバインドします。 3.RM は TC に登録し、ブランチ トランザクションを XID で表されるグローバル トランザクションに関連付けます。 4.RMは分岐トランザクションの実行結果をTCに報告します。 (オプション) 5.TC はブランチ コミットまたはブランチ ロールバック コマンドを RM に送信します。

Seata のグローバル トランザクション処理プロセスは、次の 2 つの段階に分かれています: 実行段階: ブランチ トランザクションを実行し、実行結果がロールバック可能で永続的であることを確認します。完了フェーズ: 実行フェーズで行われた決定に基づいて、アプリケーションは TM を介して TC にグローバル コミットまたはロールバック要求を送信し、TC は RM にブランチ トランザクションをコミットまたはロールバックするように指示します。 Seata のいわゆるトランザクション モードは、Seata グローバル トランザクション フレームワークの下で実行されるブランチ トランザクションの動作モードを指します。正確には、ブランチトランザクションモードと呼ぶべきでしょう。異なるトランザクション モード間の違いは、ブランチ トランザクションでは、グローバル トランザクションの 2 つのステージの目標を達成するために異なる方法を使用することです。つまり、次の 2 つの質問に答えます。実行フェーズ: 実行方法と、実行結果がロールバック可能で永続的であることを保証する方法。完了フェーズ: TCのコマンドを受信した後、トランザクションはロールバック/コミットされます。

2. では、Seata XA モデルとは何ですか?

XA モード: Seata が定義する分散トランザクション フレームワークにおいて、XA プロトコルのトランザクション リソース (データベース、メッセージ サービスなど) のサポートを利用して、XA プロトコルのメカニズムを使用してブランチ トランザクションを管理するトランザクション モード。実行フェーズ: ロールバック: ビジネス SQL 操作は XA ブランチに配置され、リソースの XA プロトコルのサポートによりロールバックが保証されます。永続性: XA ブランチが完了すると、XA 準備が実行されます。同様に、リソースの XA プロトコルのサポートにより永続性が保証されます (つまり、その後の事故によってロールバックが不可能になる状況は発生しません)。完了フェーズ: ブランチコミット: XAブランチのコミットを実行する ブランチロールバック: XAブランチのロールバックを実行する

以下は、Seataによって定義されたトランザクションモードにおけるXAモードの設計モデルの画像です。

2.1 Seata AT(TXC)モードとは何ですか?

昨年1月、SeataはATモードをオープンソース化した。 AT モードは、非侵入型の分散トランザクション ソリューションです。 AT モードでは、ユーザーは自分の「ビジネス SQL」にのみ集中する必要があります。ユーザーの「ビジネス SQL」が最初の段階であり、Seata フレームワークはトランザクションの第 2 段階のコミットおよびロールバック操作を自動的に生成します。

紹介を通じて、AT モードの特徴を実際に確認することができます。独自の業務 SQL にのみ集中すればよく、業務に侵入しない分散トランザクション モードです。では、彼がビジネスにおいて非干渉性をどのように実現できるかを知る必要があるでしょうか?

2.2 AT モードはどのようにしてサービスへの非侵入性を実現するのでしょうか?

ATモードステージ1

• まず、Seata のコンポーネントで分散トランザクションを有効にする場合は、ビジネス エントリまたはトランザクション開始エントリに @GlobalTransactional アノテーションを追加する必要があります。
• AT モードの場合は、データ ソース プロキシ (seata1.0 は自動プロキシを完全にサポート) を作成し、sqlsessionfactroy で使用する必要があります (または、プロキシされたデータ ソースを使用するために直接 jdbc 操作を使用します)。

重要な非同期性はプロキシ データ ソースであり、他のモードとは異なることがわかります。プロキシ データ ソースの秘密は何ですか?

上の図に示すように、データ ソースが DataSourceProxy によってプロキシされた後、実行した SQL が抽出され、解析され、前面の画像が保存されます。その後、業務SQLを実行し、バックイメージを保存しておくことで、後から例外が発生した場合でも2段階のロールバック操作が行えます。

2.3 ATモードでの分離を確保する方法

まず、より直感的な説明のために、公式 Web サイトにドキュメントを表示してみましょう。

上の図から次のことが結論付けられます。

最初のフェーズでローカル トランザクションをコミットする前に、まずグローバル ロックが取得されていることを確認する必要があります。

グローバル ロックを取得できないため、ローカル トランザクションをコミットできません。

グローバル ロックを取得しようとする試みは、特定の範囲に制限されます。範囲外の試行は中止され、ローカル トランザクションはロールバックされてローカル ロックが解放されます。

2 つのグローバル トランザクション tx1 と tx2 はそれぞれテーブル a の m フィールドを更新します。 mの初期値は1000です。

最初に tx1 が開始され、ローカル トランザクションを開き、ローカル ロックを取得し、操作 m = 1000 - 100 = 900 を更新します。

ローカル トランザクションをコミットする前に、まずレコードのグローバル ロックを取得し、次にローカル トランザクションをコミットしてローカル ロックを解除します。

tx2 の後、ローカル トランザクションが開始され、ローカル ロックが取得され、更新操作 m = 900 - 100 = 800 が実行されます。

ローカル トランザクションがコミットされる前に、レコードのグローバル ロックを取得してみてください。 tx1がグローバルにコミットされる前に、

レコードのグローバル ロックは tx1 によって保持されており、tx2 はグローバル ロックを待機して再試行する必要があります。 tx2 がタイムアウトすると、tx2 はローカル トランザクションをロールバックして、ダーティ データを生成しないようにします。

AT モード 2 フェーズ コミット

第 2 ステージが送信される場合、「ビジネス SQL」は第 1 ステージでデータベースに送信されているため、Seata フレームワークは、第 1 ステージで保存されたスナップショット データと行ロックを削除するだけで、データのクリーンアップを完了できます。

ATモード2段階ロールバック

第 2 段階がロールバックされた場合、Seata は第 1 段階で実行された「業務 SQL」をロールバックし、業務データを復元する必要があります。ロールバック方式は、「以前のイメージ」を使用してビジネス データを復元することです。ただし、復元する前に、まずダーティ ライトを確認し、「データベースの現在のビジネス データ」と「後のイメージ」を比較する必要があります。 2 つのデータ コピーが完全に一致している場合は、ダーティ ライトがなく、ビジネス データを復元できることを意味します。不一致がある場合は、ダーティ ライトが発生していることを意味し、ダーティ ライトは手動で処理する必要があります。

Seata によって策定されたトランザクション モデルに基づく完全な AT モデル図:

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

まず、ATから判断する必要があります。 Seata は AT モードがあるのに、なぜ XA をサポートするのでしょうか?

• 視点から：まずはATモードについてまとめます。まず、すべてのトランザクションは TM (AT だけでなく) から開始され、読み取りコミットされたデータはアプリケーション (ユーザーが開発したシステム) 内でのみ有効になります。リソース ビューは包括的ではありません。 XA を使用すると、リソースはグローバル トランザクション内にあることも認識できます。リソースの分離はデータベース自体によって実現され、グローバルな一貫性が満たされます。
• 侵入とデータベース サポートの観点から見ると、非侵入型ビジネスはより徹底的であり、2 つ未満のサービスが関与する操作では、ローカル トランザクションのみを使用して一貫性を実現できますが、AT では分離を確保するためにグローバル ロックが必要です。したがって、1 つのサービス、単一のデータベース操作、または n 個のサービスであっても、分離を保証するためにグローバル トランザクションを有効にする必要があります。データベースのサポートについては、AT が MySQL、PGSQL、Oracle 以外のデータベースをサポートする必要がある場合、適応が必要となり、複雑な SQL を解析するコストが高くなり、開発効率が低下し、サポートされる SQL の数が少なくなります。 XA は、データベース SQL ステートメントの多言語サポートを完全にサポートできます。 Seata XA を使用した Java アプリケーションがある場合、ローカル データベースによって分離を確保できます。 Seata がサポートしていない他の言語を Java と並行して処理しても、データの不整合は発生しません。

4. Seata が XA モードをサポートするのはなぜですか?

• データ ロック: トランザクション処理プロセス全体が終了する前に、関係するすべてのデータがロックされ、分離レベルの定義に従って読み取りと書き込みが制限されます。
• AT モードでは、基本的な書き込み分離を確保するためにグローバル ロックが使用されます。実際にはデータもロックされますが、ロックは TC 側で集中管理されるため、ロック解除効率が高く、ブロッキングの問題もありません。さらに、XA ローカル データベースはギャップ ロックを保持する可能性があり、その結果、ロックの粒度が大きくなり、より多くの無害なデータがロックされることになります。
• デッドロック (プロトコル ブロッキング): XA 準備後、ブランチ トランザクションはブロッキング フェーズに入り、XA コミットまたは XA ロールバックが受信されるまで待機する必要があります。信頼できるコーディネータがない場合、たとえば、3 つのデータベース abc のデータが第 2 フェーズで送信されることが決定され、ab が指示を受信して​​送信したが、c データベースが指示を受信した後にハングして xa トランザクションを送信しない、またはコーディネータが第 2 フェーズの再試行を実行しなかった場合、送信されていない xa トランザクションは常にロックを保持し、デッドロック状態が発生します。
• パフォーマンスの低下: パフォーマンスの低下は主に 2 つの側面から生じます。一方では、トランザクション調整プロセスによって単一トランザクションの RT が増加します。一方、同時トランザクション データのロック競合によりスループットが低下します。実際、主な理由は、xa の最初のステージが送信されないため、上記のブロックとデータ ロックが発生することです。最初のステージがサブミットされた場合、At モードの 1 ステージ サブミットにより、複数のライブラリがローカル ロックを解放する必要がなく、tc 側で集中的にロックおよび解放されるため、at のパフォーマンスは xa よりも優れています。

ATとXAの関係

まず、AT と XA はどちらも、データの一貫性と分離を確保するためにデータベースのトランザクション機能を使用することを明確にする必要があります。

たとえば、AT の第 1 フェーズのコミットと第 2 フェーズのロールバックはどちらもローカル トランザクションを実行します。たとえば、XA の第 1 フェーズと第 2 フェーズでは、データベース自体のトランザクション特性も利用されます。

では、データベース レベルで AT と XA の関係を調べる必要があるでしょうか?

まず、この時点で、類似点と相違点を見つけなければなりません。最初に影響を受けるのは AT です。必需品である、undolog テーブルを備えています。データベースに精通している学生なら、必ず知っておくべきだと思います。データベースには、REDO ログ、UNDO ログ、バイナリ ログ、エラー ログ、スロー クエリ ログ、一般ログ、リレー ログの 6 種類のログがあります。

では、データベース undolog は何に使用されるのでしょうか? Undolog はトランザクションが発生する前にデータのバージョンを保存します。これはロールバックに使用でき、マルチバージョン同時実行制御 (MVCC) の下で読み取りを提供できます。

データベース undolog と seata at mode undolog は同じ機能を持っていることがわかります。したがって、at モードの undolog は、分散トランザクションを実現するためにローカル トランザクション内の undolog を使用し、分散トランザクション下でのトランザクションの一貫性を確保するものであると判断できます。

では、undolog について話した後、redolog についてはどうでしょうか?

Redolog の役割は、障害発生時にダーティ ページがディスクに書き込まれるのを防ぐことです。 MySQL サービスを再起動すると、REDO ログに従って再実行が実行され、トランザクションの永続性が実現されます。

では、なぜ Seata AT モードで redolog の存在を確認できないのでしょうか?実のところ、それは非常に簡単です。この redolog は非常に深く隠されています。つまり、AT モードの 1 段階コミットにより、データベースが redolog として機能し、最初の段階のデータがディスクに正確に保存されることが保証されます。

このとき、LCN トランザクション モードを考えていますか?その undolog はデータベースによって保証されており、redolog はありません。実際、LCN 取引を見逃す必要はありません。ここで解析してみると、1 段階でコミットしないように AT を変更すると、2 段階でコミットするときに、前面イメージは undolog、背面イメージは redolog になります。つまり、AT は実際にはデータベース レベルではありませんが、データベース トランザクションの考え方と実装原則に従って、分散モードでトランザクションの一貫性を実現する方法です。

この時点で、XA と AT の関係は明らかになっているはずです。正確に言うと、分散トランザクションとデータベースのローカルトランザクションの関係であると言えます。 XA の欠点が、複数の側 (複数のライブラリ) をロックし、リソースをブロックし、パフォーマンスが低下する AT モードの誕生につながったと言えます。

AT は、トランザクション実装の意思決定権をデータベースから Seata に移し、SQL 解析を自己実装し、undolog (redolog) を自己実装するようなものです。分散トランザクションにおけるデータベースの問題を直接最適化する方法はないため、不要な部分を取り除き、本質を保持する新しいモデルを作成する方が適切です。

Seata ATとXAの長所と短所

実際、私はそれぞれの利点と欠点について上で多く述べてきました。それでは3つのポイントでまとめて比較してみましょう。

• SQL サポート
• 分離
• 侵襲的

まず最初の点についてお話ししましょう。上記でまとめたように、AT は実際には自己実装された XA トランザクションであるため、AT の SQL サポートはローカル トランザクションを使用する XA モードに比べてはるかに劣っていることがわかります。 AT は SQL 解析を行う必要があるため、その背後にある実装は私たち自身でのみ解決できます。つまり、Seata コミュニティの貢献者がソリューションを提供することに頼ることになります。これは長期的な重要な問題ですが、AT トランザクション モードのサポートを取得するために SQL を書き直すことを選択するユーザーはまだ多くいます。 SQLサポートに関しては、XAが間違いなく勝者である

2番目のポイントは分離です。 Seata AT モードは、SQL を解析して関連する主キー ID を取得し、行ロックを生成します。つまり、AT モードの分離は、行レベルまでの粒度を持つグローバル ロックによって保証され、ロック情報は Seata サーバー側に保存されます。 XA モードの分離はローカル データベースによって保証され、ロックは各ローカル データベースに保存されます。 XA モードで準備が実行されると、XA トランザクションを再入力することはできなくなります。また、他の XA トランザクションとロックを共有することもできなくなります。 XA プロトコルは XID を介してのみ XA トランザクションを開始するため、いわゆるブランチ トランザクション自体は存在しません。これは単なる XA トランザクションであり、つまりそれ自体のことだけを考慮します。この時点で、一部の学生から「なぜ branch_table に XA ブランチ トランザクションが表示されるのか」という疑問が湧くかもしれません。実際、この質問は上記の「Seata トランザクション モードとは何ですか?」から理解できます。 Seata のトランザクション モードは、グローバル トランザクション、ブランチ トランザクション、およびロック情報で構成されます。 XA ブランチ トランザクションは参加者としてのみ存在します。つまり、この XA ブランチは Seata 定義のブランチ トランザクションであり、ブランチ情報として記録されるため、ダウンタイム後に第 2 段階の解決情報を発行できます。 AT ロックは XA とは異なり、自己実装されているため、ユーザーの SQL に含まれるデータと、そのデータがグローバル トランザクションの下にあるかどうかがわかっていれば、デフォルト設定であれば、ユーザーはこのロックを使用でき、再エントリの問題が解決されます。 XA の分離はグローバルであるのに対し、AT の分離はより柔軟で比較的グローバルである (データへのすべての書き込み操作が Seata トランザクションによってカバーされることを保証する) と結論付けることができます。 3つ目のポイントは侵襲性です。上記の情報から、実際にはレベルが低いほど侵入性が低いことがわかります。したがって、データベース自体でサポートされている XA モードは、間違いなく最も侵襲性が低く、使用コストが最も低くなります。

実際、この時点で、XA モードは AT モードよりもはるかに優れていると思われるかもしれません。ロックの再入力はサポートされていませんが、この状況は回避できます。今回は絵を描いてみました。もっと分かりやすいと思います

上図において、右側の図 1 はシステムが at モードで実行されているとき、図 2 はシステムが xa モードで実行されているときです。特にブランチ トランザクションが多数ある場合、XA のブロックによって引き起こされるパフォーマンスの低下が非常に深刻であることは明らかです。各リソースの解放は、後続のトランザクションが入力できるようになる前に、各ブランチのデータベースが個別に解放されるまで待機する必要があります。 XA は非侵入性が非常に高いものの、パフォーマンスの低下が大きすぎるため、AT が誕生しました。現在、AT、TCC、SAGA モデルの受け入れがますます高まっており、これは開発者のパフォーマンスに対する要件も示しています。 AT は、Seata コミュニティによって完全に最適化された独自開発の XA モードと見なすことができます。その最大の特徴は、XA モードのパフォーマンス低下の問題を解決したことです。 TCC は 2 フェーズのステータス通知用に Seata によって決定され、その使用は完全にユーザーに委ねられており、パフォーマンスは 2 つのローカル トランザクション + わずかな RPC オーバーヘッドのみです。 SAGA のトランザクション チェーン全体において、トランザクション処理はオーケストレーションのためにユーザーに完全に委託され、パフォーマンスはユーザーによって完全に保証されます。 Seata はトランザクション アシスタントとして、グローバル トランザクションの実行ステータスを記録します。モードの侵襲性が高くなるほど、その背後で最適化できるポイントが増えることがわかります。モードの侵襲性が低いほど、制限が多くなり、コンポーネント開発者が不規則な最適化を実行することによってのみパフォーマンスを保証できます。

要約する

現在の技術発展において、分散型トランザクションは現在、東風の役割を果たしています。多数の分散サービスとマイクロサービスによりパフォーマンスが明らかに向上しましたが、好ましい保証はありません。シータがそのような役割を果たし、すべてが準備されていると信じています。 Seata プロジェクトの核となる価値は次のとおりです。

分散トランザクションの問題を包括的に解決する標準化されたプラットフォームを構築します。

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

写真

注: この共有は、Seataの3つのPMCであるQingming、Xuanyu、Yiyuanに基づいています。

寄稿者: Chen Jianbin (funkye) github id: a364176773

著者について: Tongdun Technology のシニア開発エンジニア、Seata コミッター、Spring cloud alibaba コントリビューター、Mybatis-Plus コントリビューター (by dynamic-datasource)