「大企業で働きたい」 - 分散トランザクション

[[376830]]

分散トランザクションに関しては、なぜ分散トランザクションが存在するのかを誰もが知っておくべきだと私は思います。データ量によるデータベース シャーディングであろうと、マイクロサービスの現在の普及であろうと、これらがその出現の理由です。

この記事の内容は相変わらず陳腐です。主な範囲は、XA、2PC、3PC、TCC、そして最後にSeataです。

ただし、これは面接や理論的な理解にのみ適していると思います。これらのソリューションが実際に本番環境で使用されていると本当に言いたいのでしょうか?

はい、しかしそれはより単純に実装され、理論を適用することによって実装されることはありません。大企業には独自のソリューションがあり、中小企業はフレームワークを使用しているか、分散トランザクションの問題をまったく抱えていません。

それで、なぜこれを書くのでしょうか?

あなたのインタビューのためにエッセイを書いています、私のかわいい子よ。

取引

分散トランザクションについて話すには、まずトランザクションの基本的な特性から始める必要があります。

AAtomicity: トランザクションの実行中、すべての操作が正常に実行されるか、いずれの操作も正常に実行されません。

C 一貫性: トランザクションは実行前後のデータの整合性を破壊することはできません。一貫性とは、AID を通じて目標を達成することです。データは、事前に定義された定義と制約に準拠し、アプリケーション レベルで保証される必要があります。 C は ACID のために無理やり組み立てられていると言う人もいます。

分離: 複数のトランザクションは互いに分離されており、互いに干渉することはできません。これには、異なるトランザクションの分離レベルの問題が関係します。

DPersistence: トランザクションがコミットされると、データベース内のデータの状態は永続的になります。

1000

XA (eXtended Architecture) は、X/Open 組織によって提案された分散トランザクション処理仕様を指します。トランザクションマネージャTM(Transaction Manager)、リソースマネージャRM(Resource Manager)、およびアプリケーションプログラムを定義する仕様またはプロトコルです。

トランザクション マネージャー TM はトランザクション コーディネーターであり、リソース マネージャー RM はデータベースと見なすことができます。

2PC

XA は仕様を定義し、2PC と 3PC はその特定の実装方法です。

2PC は 2 フェーズ コミットと呼ばれ、投票フェーズと実行フェーズの 2 つのフェーズに分かれています。

投票フェーズ

TM は、すべての参加者に準備要求を送信し、トランザクションを実行できるかどうかを尋ね、各参加者からの応答を待ちます。

この段階では、トランザクションの SQL ステートメントのみが実行され、まだコミットされていないと考えられます。

すべてが正常に実行された場合は YES を返し、それ以外の場合は NO を返します。

実行フェーズ

実行フェーズは実際のトランザクション送信フェーズですが、失敗の状況を考慮する必要があります。

すべての参加者が YES を返した場合、コミット コマンドが送信され、参加者はそれを受信した後にトランザクションをコミットします。

逆に、いずれかの参加者が NO を返した場合、ロールバック コマンドが送信され、ロールバック操作が実行されます。

2PCのデメリット

1. 同期ブロッキング。トランザクションの実行中は、すべてのデータベース リソースがロックされていることがわかります。この時点で他の人がこれらのリソースにアクセスしようとすると、ブロックされてしまい、大きなパフォーマンス上の問題が生じます。
2. TM は単一点の問題です。 TMは1つだけです。 TM がダウンすると、プロセス全体を完了できなくなります。
3. データの不整合: 実行フェーズ中に参加者がブレインを分割したり、その他の障害によってコミット要求が受信されず、一部のトランザクションがコミットされ、他のトランザクションがコミットされない場合、データの不整合が発生します。

3PC

2PC には多くの問題があるため、3 フェーズ コミットとも呼ばれる 3PC の概念が派生しました。プロセス全体を CanCommit、PreCommit、DoCommit の 3 つのステップに分割します。 2PC と比較すると、追加されたステージは CanCommit ステージです。

コミット可能

この段階では、まずデータベースにトランザクションを実行するかどうかを問い合わせ、canCommit リクエストを送信して問い合わせ、実行可能な場合は YES を返し、そうでない場合は NO を返します。

事前コミット

この段階は 2PC の投票段階に相当します。 preCommit コマンドが送信され、SQL トランザクションが実行されます。成功した場合は YES が返され、それ以外の場合は NO が返されます。

ただし、ここでの違いは、参加者にタイムアウト メカニズムがあることです。参加者がタイムアウト期間内に doCommit コマンドを受信しない場合、トランザクションはデフォルトでコミットされます。

コミットする

DoCommit フェーズは、2PC の実行フェーズに対応します。前のフェーズで YES が受信された場合、トランザクションをコミットするために doCommit コマンドが送信されます。それ以外の場合は、トランザクションの実行を中断するために中止コマンドが送信されます。

2PC からの改善点

2PC の同期ブロッキング問題に関しては、3PC では参加者のタイムアウト メカニズムが追加されたため、元の 2PC で参加者の障害によって発生する同期ブロッキング問題の時間が短縮されることがわかります。これは最適化ですが、完全に回避できるわけではありません。

2 番目の単一点障害の問題も、タイムアウト メカニズムの導入により、ある程度最適化されました。

しかし、データの不一致の問題は未だ解決されていません。

例えば：

PreCommit フェーズでは、参加者はスプリット ブレイン状態になり、TM からの要求を受信できません。このとき、他の参加者はトランザクションの中止ロールバックを実行し、スプリットブレインが発生した参加者はタイムアウト後もトランザクションのコミットを継続するため、データの不整合が発生する可能性があります。

では、なぜ DoCommit ステージを追加する必要があるのでしょうか?タイムアウトメカニズムを導入することです。まず、データベースがトランザクションを実行できるかどうかを確認します。問題がなければ次のステップに進みます。すべて実行できるので、タイムアウト後に問題が発生したということになり、トランザクションが自動的にコミットされます。

TCC

TCC モードは Try、Confirm、Cancel と呼ばれ、実際には 2PC のバリエーションにすぎません。

このモードを実装するには、トランザクション インターフェイスを、プリエンプションの試行、送信の確認、ロールバックのキャンセルの 3 つの部分に分割する必要があります。

TCC に関しては、実際の制作現場でそれを使用している人を基本的に見たことがありません。その理由を検討しました。まず、プログラマー自体の質にばらつきがあります。複数のチームが協力する場合、他のチームが自分のルールに従って実装するように強制するのは困難です。もう一つの点は、複雑すぎるということです。

単純なアプリケーションがある場合、在庫アプリケーションがその 1 つとして考えられます。

一般的な在庫操作の場合、多くの実装ソリューションでは、注文時に在庫を予約し、注文が正常に行われた後に実際に在庫を差し引きます。最後に、異常が発生した場合は、インベントリがロールバックされます。

在庫を凍結して事前占有するのが 2PC の準備段階であり、注文が成功したときに実際に在庫を差し引くのが 2PC の提出段階です。ロールバックは例外が発生したときのロールバック操作ですが、アプリケーション レベルでのみ 2PC メカニズムを実装します。

サガ

Saga は、プリンストン大学の Hecto と Kenneth が 1987 年に発表した、長期間のトランザクションを処理する方法に関する論文から生まれました。

主なアイデアは、長いトランザクションを複数のローカルの短いトランザクションに分割することです。

すべて正常に実行されれば正常に完了します。それ以外の場合は、逆の順序で補償が呼び出されます。

SAGA モードには 2 つの回復戦略があります。

1. フォワードリカバリ。このモードは成功しなければならないシナリオに偏っており、失敗した場合は再試行が実行されます。
2. 後方回復とは、異常のあるサブトランザクションを一つずつロールバックして補償することを意味する。

このモデルは国内ではほとんど使用されていないため、詳しく説明しません。

メッセージキュー

メッセージ キューに基づいて最終的な一貫性を実現するソリューションは、以前のソリューションよりも少し信頼性が高いと私は考えています。これらは単なる理論であり、通常の生産ではほとんど使用されません。

メッセージ キューに基づくアプリケーションが若干増える可能性があります。

一般的に言えば、ローカル メッセージ テーブルに基づく方法と MQ 自体のトランザクション メッセージに依存する方法の 2 つがあります。

ローカル メッセージ テーブル ソリューションは実際にはより複雑であり、実際にそれを使用している人を見たことがありません。ここでは、RocketMQ のトランザクション メッセージを例に挙げます。この方法は、ローカル メッセージ テーブルと比較して、分離のために MQ 自体の特性にさらに完全に依存するため、ビジネス開発の複雑な作業負荷が軽減されます。

1. ビジネス イニシエーターはリモート インターフェイスを呼び出し、セミトランザクション メッセージを MQ に送信します。メッセージを受信した後、MQ はプロデューサーに ACK を返します。
2. プロデューサーは ACK を受信するとトランザクションを実行しますが、トランザクションはまだコミットされていません。
3. プロデューサーは、トランザクションの実行結果に基づいて、MQ にコミットまたはロールバックを送信するかどうかを決定します。
4. これは、プロデューサーがクラッシュしたり、その他の異常によって MQ がコミット メッセージやロールバック メッセージを長時間受信しなくなったりするなど、異常な状況が発生した場合です。この時点で、MQ はステータス チェックを開始します。
5. MQ がコミットを受信すると、メッセージが配信され、コンシューマーはメッセージを通常どおりに使用できます。ロールバックの場合、設定された一定期間内にメッセージは削除されます。

このソリューションは MQ に基づいており、メッセージ トランザクションの最終的な一貫性を保証します。それは比較的合理的な解決策です。 MQ の信頼性が保証されている限り、アプリケーションは正常に実装でき、ビジネス コンシューマーは独自のメッセージ再試行に基づいて最終的な一貫性を実現できます。

フレーム

上記はすべて理論であり、それを自分で実装する方法です。では、私たちの問題を解決するための分散トランザクションのフレームワークは存在しないのでしょうか?

はい、実際はかなりの数いますが、旗手はいません。あるとすれば、Alibaba のオープンソース フレームワーク Seata と Alibaba Cloud の GTS です。

GTS（Global Transaction Service）は、Alibaba Cloud のミドルウェア製品です。 Alibaba Cloud を使用し、料金を支払っている限り、GTS を使用できます。

Seata (Simple Extensible Autonomous Transaction Architecture) は、TCC、XA、Saga、および AT モードをサポートするオープン ソースの分散トランザクション フレームワークです。

それで、GTS と Seata とは何の関係があるのでしょうか?

実際、当初はすべて Alibaba の内部 TXC (Taobao Transaction Constructor) 分散ミドルウェア製品に基づいていましたが、その後 TXC が改良され Alibaba Cloud 上に配置され、GTS と呼ばれました。

その後、アリババのミドルウェアチームは、TXC と GTS をベースにしたオープンソースの Seata を作成しました。その中で、AT (自動トランザクション) モードは GTS の独自のソリューションでした。

現在のバージョンに関しては、ほぼ同じであると想定できます。 2020 年までに、GTS は Seata の GA バージョンと完全に互換性を持つようになりました。

画像はAlibaba Cloud公式サイトGTSより

GTS または Seata 全体には、次のコア コンポーネントが含まれています。

• トランザクション コーディネーター (TC): トランザクション コーディネーターは、グローバル トランザクションの実行ステータスを維持し、グローバル トランザクションのコミットまたはロールバックの調整と実行を担当します。
• トランザクション マネージャー (TM): グローバル トランザクションの境界を制御し、グローバル トランザクションの開始を担当し、最終的にグローバル コミットまたはグローバル ロールバックの決定を開始します。
• リソース マネージャー (RM): ブランチ トランザクションを制御し、ブランチの登録とステータス レポートを担当し、トランザクション コーディネータから指示を受け取り、ブランチ (ローカル) トランザクションのコミットとロールバックを実行します。

TCC のサポートであろうと、独自の AT モードであろうと、分散トランザクション全体の原理は比較的理解しやすいです。

1. トランザクションが開始されると、TM は TC にグローバル トランザクションを登録し、グローバル トランザクション XID を取得します。
2. このとき、複数のマイクロサービスのインターフェースが呼び出されると、XID が各マイクロサービスに伝播され、トランザクションを実行する各マイクロサービスも TC に分岐トランザクションを登録します。
3. その後、TM は各 XID のトランザクションのグローバル コミットとロールバックを管理し、RM はブランチのコミットまたはロールバックを完了します。

コアコンポーネントの定義 - Alibaba Cloud 公式サイトからの画像

ATモード

TCC ソリューションと比較すると、元の AT モードでは複数のインターフェイスを単独で実装する必要がありません。プロキシ データ ソースの形式で更新の前後に UNDO_LOG を生成し、UNDO_LOG を使用してロールバック操作を実装します。

実行プロセスは次のとおりです。

1. TMはTCにグローバルトランザクションを登録し、XIDを取得する
2. RM は JDBC データ ソースをプロキシし、ミラー化された SQL を生成し、UNDO_LOG を形成し、次にブランチ トランザクションを TC に登録して、データ更新と UNDO_LOG をローカル トランザクションで一緒に送信します。
3. TC がコミット要求を受信すると、対応するブランチの UNDO_LOG を非同期的に削除します。ロールバックの場合は、対応するブランチの UNDO_LOG を照会し、UNDO_LOG を通じてロールバックを実行します。

トランザクションモード - AT - Alibaba Cloud 公式サイトからの画像

TCC モード

UNDO_LOG を生成して逆 SQL ロールバックを生成する AT モード プロキシ JDBC データ ソースと比較すると、TCC は少し単純です。

1. TMはTCにグローバルトランザクションを登録し、XIDを取得する
2. RMはTCに分岐トランザクションを登録し、Tryメソッドを実行してTryメソッドの実行ステータスを報告します。
3. その後、TC からコミット要求を受信すると Confirm メソッドが実行され、ロールバックを受信すると Cancel メソッドが実行されます。

トランザクションモード - TCC - Alibaba Cloud 公式サイトからの画像

XA モード

1. TMはTCにグローバルトランザクションを登録し、XIDを取得する
2. RMはTC、XA Startで分岐トランザクションを登録し、SQL、XA END、XA Prepareを実行し、分岐実行ステータスを報告します。
3. その後、TC からコミット要求を受信すると Confirm メソッドが実行され、ロールバックを受信すると Cancel メソッドが実行されます。

トランザクションモード - XA - Alibaba Cloud 公式サイトからの画像

SAGAモード

• TMはTCにグローバルトランザクションを登録し、XIDを取得する
• RMはTCにブランチトランザクションを登録し、ビジネスメソッドを実行してブランチ実行ステータスを報告します。
• RMはブランチロールバックを受信し、対応するビジネスロールバックメソッドを実行します。

トランザクションモード - Saga - Alibaba Cloud 公式サイトからの画像

要約する

ここでは、トランザクションの ACID から始め、XA は分散トランザクション処理の仕様であることをお伝えします。次に、2PC と 3PC について説明します。 2PC には、同期ブロッキング、単一点障害、データの不整合などの問題があります。 3PC は、同期ブロッキングと単一点障害の問題をある程度解決しますが、データの不整合の問題は完全には解決されません。

次に、TCC、SAGA、メッセージ キューの最終的な一貫性ソリューションについて説明しました。 TCC は実装が面倒で複雑すぎるため、ビジネスではほとんど使用されません。 SAGA は理解できればよいのですが、中国ではほとんど使用されません。メッセージ キューは分離された実装方法を提供するため、中小企業にとっては比較的低コストの実装方法となる可能性があります。

最後に、現在の国内実施体制についてお話しします。クラウド上のAlibaba CloudのGTSはSeataと互換性があり、非クラウド側ではSeataが使われています。現在の主流ともいえる XA、TCC、AT、SAGA 向けのソリューションを提供します。

この記事はWeChatの公式アカウント「艾小仙」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、艾小仙の公式アカウントまでご連絡ください。