分散トランザクションを解決するにはどうすればいいでしょうか?きっぱりと明らかにしましょう!

[[409803]]

分散トランザクションの基礎

取引

トランザクションとは操作単位を指します。この操作単位内のすべての操作は、最終的に一貫した動作を維持する必要があります。すべての操作が成功するか、すべての操作がキャンセルされます。簡単に言えば、トランザクションは「何もしないか、すべてを行うか」のメカニズムを提供します。

地方問題

ローカルトランザクションは、実際にはデータベースによって提供されるトランザクションメカニズムと考えることができます。データベーストランザクションに関しては、データベーストランザクションの 4 つの主要な特性について説明する必要があります。

A：原子性(Atomicity) : トランザクション内のすべての操作は、完了するか、完了しないかのいずれかです。

C：一致性(Consistency)トランザクションが実行される前と実行後に、データベースは一貫した状態になっている必要があります。

I：隔离性(Isolation) : 並行環境では、異なるトランザクションが同時に同じデータに対して操作を行う場合、トランザクションは互いに影響を及ぼしません。

D：持久性(Durability) 。トランザクションが正常に終了する限り、データベースへの更新は永続的に保存される必要があることを意味します。

データベーストランザクションを実装する場合、トランザクションに関係するすべての操作は、分割できない実行単位に含められます。実行ユニット内のすべての操作は成功するか失敗します。いずれかの操作が失敗した場合、トランザクション全体がロールバックされます。

分散トランザクション

分散トランザクションとは、トランザクション参加者、トランザクションをサポートするサーバー、リソースサーバー、およびトランザクションマネージャーが、異なる分散システムの異なるノードに配置されていることを意味します。

簡単に言えば、大規模な操作はさまざまな小規模な操作で構成されています。これらの小さな操作は異なるサーバーに分散され、異なるアプリケーションに属します。分散トランザクションでは、これらの小さな操作がすべて成功するか、すべて失敗するかを保証する必要があります。

本質的に、分散トランザクションは、異なるデータベース間でのデータの一貫性を確保するように設計されています。

分散トランザクションのシナリオ

複数のデータベースにアクセスするモノリシックシステム
サービスは、データの追加、削除、変更操作を完了するために複数のデータベースインスタンスを呼び出す必要があります。

複数のマイクロサービスが同じデータベースにアクセスする
データの追加、削除、変更操作を完了するには、複数のサービスがデータベースインスタンスを呼び出す必要があります。

複数のマイクロサービスが複数のデータベースにアクセスする
データの追加、削除、変更操作を完了するには、複数のサービスがデータベースインスタンスを呼び出す必要があります。

分散トランザクションソリューション

グローバル取引

グローバルトランザクションは DTP モデルに基づいて実装されます。 DTP は、X/Open 組織によって提案された分散トランザクションモデル ( X/Open Distributed Transaction Processing Reference Modelです。分散トランザクションを実装するには、次の 3 つの役割が必要であると規定されています。

AP: アプリケーションシステム（マイクロサービス）
TM: トランザクションマネージャ (グローバルトランザクション管理)
RM: リソースマネージャーリソースマネージャー (データベース)

取引全体は 2 つの段階に分かれています。

フェーズ 1: 投票フェーズでは、すべての参加者がトランザクションを事前送信し、それが成功するかどうかについてのフィードバックをコーディネーターに送信します。

フェーズ 2: 実行フェーズ。コーディネーターはフィードバックに基づいてすべての参加者に通知し、コミットまたはロールバックを同時に実行します。

アドバンテージ：

データの一貫性の確率を高め、実装コストを削減します

欠点:

単一障害点: トランザクションコーディネーターのダウンタイム
同期ブロッキング: 送信時間を遅らせ、リソースのブロッキング時間を延長します
データの不整合: 第2フェーズを送信するときに、コミット結果が不明な状況がまだ存在し、データの不整合につながる可能性があります。

信頼性の高いメッセージングサービス

信頼性の高いメッセージサービスに基づくソリューションは、メッセージミドルウェアを通じて上流と下流のアプリケーションデータ操作の一貫性を確保することです。

タスク A とタスク B をそれぞれ処理できる 2 つのシステム A と B があるとします。このとき、タスク A とタスク B を同じトランザクションで処理する必要があるビジネスプロセスが存在します。この分散トランザクションを実装するには、メッセージミドルウェアを使用できます。

ステップ1: メッセージはシステムAからミドルウェアに配信される

システムAがタスクAを処理する前に、まずメッセージミドルウェアにメッセージを送信する。
メッセージミドルウェアは、メッセージを受信した後、メッセージを保持しますが、配信は行いません。永続化が成功すると、確認応答がAに送信されます。
システムAが確認応答を受信すると、タスクAの処理を開始できる。
タスク A が処理された後、コミットまたはロールバック要求がメッセージミドルウェアに送信されます。リクエストが送信されると、システム A のトランザクション処理が完了します。
メッセージミドルウェアが Commit を受信すると、メッセージをシステム B に配信します。ロールバックを受信した場合、メッセージを直接破棄します。ただし、メッセージミドルウェアがコミットおよびロールバックの指示を受信しない場合は、「タイムアウトクエリメカニズム」に依存する必要があります。

タイムアウト照会メカニズムシステム A では、通常のビジネスプロセスを実装するだけでなく、メッセージミドルウェアが呼び出すトランザクション照会インターフェイスも提供する必要があります。メッセージミドルウェアはパブリッシュメッセージを受信すると、タイミングを開始します。制限時間内に確認指示が受信されない場合は、システム A が提供するトランザクションクエリインターフェイスを積極的に呼び出して、システムの現在の状態を照会します。このインターフェースは 3 つの結果を返し、ミドルウェアは 3 つの結果に基づいて異なる応答を行います。

送信: メッセージをシステムBに配信する
ロールバック: メッセージを直接破棄する
処理中: 待機を続行

ステップ2: メッセージはミドルウェアによってシステムBに配信される

メッセージミドルウェアはメッセージを下流のシステムに配信した後、ブロックされた待機状態になります。下流システムはタスクを直ちに処理し、タスクが処理された後、メッセージミドルウェアに応答を返します。

メッセージミドルウェアが確認応答を受信すると、トランザクションが完了したとみなされます。
メッセージミドルウェアが確認応答を待機中にタイムアウトした場合、下流のコンシューマーが正常な消費応答を返すまでメッセージを再配信します。

信頼性の高いメッセージングサービスに基づく分散トランザクションでは、前半はパフォーマンスを重視して非同期処理を使用します。後半は同期処理を中心に開発コストに注力します。

ベストエフォート通知

ベストエフォート通知 (定期的な校正とも呼ばれる) は、2 番目のソリューションをさらに最適化したものです。エラーメッセージを記録するためのローカルメッセージテーブルを導入し、失敗したメッセージの定期的な校正機能を追加して、メッセージが下流のシステムで確実に使用されるようにします。

ステップ1: メッセージはシステムAからミドルウェアに配信される

処理業務の同じトランザクションで、ローカルメッセージテーブルにレコードを書き込む
専用のメッセージ送信者を用意して、ローカルメッセージテーブルからメッセージミドルウェアにメッセージを継続的に送信し、送信が失敗した場合は再試行します。

ステップ2: メッセージはミドルウェアによってシステムBに配信される

メッセージミドルウェアは、メッセージを受信した後、対応する下流システムにメッセージを同期的に配信し、下流システムでタスクの実行をトリガーする役割を担います。
下流のシステムがメッセージを正常に処理すると、メッセージミドルウェアに確認応答が送信され、メッセージミドルウェアはメッセージを削除してトランザクションを完了できます。
配信に失敗したメッセージについては、再試行メカニズムを使用して再試行します。配信に失敗したメッセージについては、エラーメッセージテーブルを記述します。
メッセージミドルウェアは、失敗したメッセージのクエリインターフェイスを提供する必要があります。下流のシステムは定期的に失敗したメッセージを照会し、それらを消費します。

このアプローチの利点と欠点:

利点: 最終的な一貫性を実現する非常に古典的な実装。

デメリット: メッセージテーブルはビジネスシステムに結合されます。カプセル化されたソリューションがない場合、さまざまな雑多な作業が必要になります。

TCC業務

TCC は Try Confirm Cancel の略で、補償分散トランザクションです。 TCC は、分散トランザクションを次の 3 つのステップで実装します。

試す: 実行するビジネスを試します。このプロセスはビジネスを実行するのではなく、すべてのビジネスの一貫性チェックを完了し、実行に必要なすべてのリソースを予約するだけです。
確認: ビジネスチェックを実行せずにビジネス操作の実行を確認し、試行フェーズで予約されたビジネスリソースのみを使用します。
キャンセル: 保留中のビジネスと、試行フェーズで予約されたビジネスリソースをキャンセルします。

TCC 2 フェーズコミットと XA 2 フェーズコミットの違いは次のとおりです。

XA は、強力な一貫性を備えたリソースレベルの分散トランザクションです。 2 フェーズコミットプロセス全体を通じて、リソースロックは常に保持されます。

TCC は、最終的な一貫性を備えたビジネスレベルの分散トランザクションであり、常にリソースロックを保持するわけではありません。

TCC 取引の利点と欠点:

アドバンテージ：

データベース層の 2 フェーズコミットは実装のためにアプリケーション層に移動され、データベース層での 2PC パフォーマンスの低下の問題を回避します。

欠点:

TCC の Try、Confirm、Cancel 操作機能はビジネス側で提供する必要があり、開発コストが高くなります。

サガ

Saga は補償プロトコルです。 Saga モードでは、分散トランザクションに複数の参加者が存在します。各参加者はリバース補償サービスであり、ユーザーはビジネスシナリオに基づいてフォワード操作とリバースロールバック操作を実装する必要があります。

補償プロトコル: Saga モードでは、分散トランザクションに複数の参加者が存在し、各参加者は正の補償サービスです。上図において、 T1~Tnは転送コール、 C1~Cnは補償コールです。転送呼び出しと補償呼び出しの間には 1 対 1 の対応があります。

呼び出されるサービスが n 個あると仮定します。T1 T1サービス 1 への呼び出し、続いてT2はサービス 2 への呼び出し、T3 はサービス 3 への呼び出しです。この時点で失敗が返された場合は、ロールバックが必要です。このとき、 T2の対応する補償C2が呼び出され、 T1の対応する補償C1が呼び出されて、分散トランザクションが初期状態に戻ります。

Saga のポジティブサービスと補償サービスはどちらもビジネス開発者によって実装される必要があるため、ビジネスに干渉します。 Saga モードの分散トランザクションは通常、イベント駆動型であり、参加者間で非同期的に実行されます。 Saga モードは、長いトランザクションソリューションです。

Sagaパターンの使用シナリオ

Saga モードは、トランザクションの最終的な一貫性を保証する必要がある長いビジネスプロセスを持つビジネスシステムに適しています。 Saga モードは、最初の段階でローカルトランザクションをコミットし、ロックフリーおよび長いプロセスでのパフォーマンスを保証できます。

トランザクションの参加者は、他社のサービスやレガシーシステムである場合があります。これらは変換できず、TCC に必要なインターフェースを提供できません。 Sagaパターンが使用可能です。

サガパターンの長所と短所

利点:

ローカルデータベーストランザクションの 1 フェーズコミット、ロックフリー、高パフォーマンス。

参加者はトランザクション駆動型の非同期実行を使用できます。高スループット補償サービスは、フォワードサービスの「逆」であり、理解しやすく実装しやすいサービスです。

欠点:

Saga モードでは、ローカルデータベーストランザクションが最初のフェーズでコミットされており、「予約」アクションが実行されていないため、分離は保証されません。

シータ

2019年1月、アリババのミドルウェアチームは、分散トランザクションの使用をローカルトランザクションと同じくらいシンプルかつ効率的にし、開発者が分散トランザクションで遭遇するすべての問題を徐々に解決するというビジョンを掲げ、オープンソースプロジェクトFescar（Fast & EaSy Commit And Rollback）を立ち上げました。その後、分散トランザクションソリューションである、シンプルで拡張可能な自律トランザクションアーキテクチャを意味する Seata に名前が変更されました。

Seata の設計目標はビジネスに支障をきたさないことであり、そのため、まずは支障をきたさない 2PC ソリューションから始めて、従来の 2PC をベースに進化していきます。分散トランザクションを、複数のブランチトランザクションを含むグローバルトランザクションとして認識します。グローバルトランザクションの責任は、管轄下にあるブランチトランザクションを調整して合意に達し、一緒に正常に送信し、失敗した場合は一緒にロールバックすることです。さらに、ブランチトランザクション自体は通常、リレーショナルデータベースのローカルトランザクションです。

Seata は主に 3 つの重要なコンポーネントで構成されています。

TC: トランザクションコーディネーター。グローバルブランチトランザクションのステータスを管理し、グローバルトランザクションのコミットとロールバックに使用されます。

TM: トランザクションマネージャー。グローバルトランザクションを開始、コミット、またはロールバックするために使用されます。

RM: リソースマネージャー。ブランチトランザクションのリソース管理、TC へのブランチトランザクションの登録、ブランチトランザクションのステータスの報告、および TC からのブランチトランザクションのコミットまたはロールバックコマンドの受け入れに使用されます。

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

サービス A の TM は、TC にグローバルトランザクションを開くように要求します。次に、TC はグローバルトランザクションを作成し、一意の XID を返します。
サービスAのRMは、TCにブランチトランザクションを登録し、XIDに対応するグローバルトランザクションの管轄に含める。
サービスAはブランチトランザクションを実行し、データベースに対して操作を実行します。
サービス A がリモートでサービス B の呼び出しを開始し、XID がマイクロサービス呼び出しチェーンに伝播します。
サービス B の RM は、ブランチトランザクションを TC に登録し、XID に対応するグローバルトランザクションの管轄下に置きます。
サービスBはブランチトランザクションを実行し、データベースに対して操作を実行します。
グローバルトランザクション呼び出しチェーンが処理された後、TM は例外があるかどうかに基づいて、TC へのグローバルトランザクションのコミットまたはロールバックを開始します。
TCは管轄下にあるすべての支部業務を調整し、ロールバックするかどうかを決定します。

Seata の 2PC 実装と従来の 2PC の違い:

アーキテクチャレベルに関して言えば、従来の 2PC ソリューションの RM は実際にはデータベース層にあります。 RM は本質的には XA プロトコルを通じて実装されたデータベースそのものです。一方、Seata の RM は、jar パッケージの形式でミドルウェアレイヤーとしてアプリケーション側に展開されます。
2 フェーズコミットに関して、従来の 2PC では、第 2 フェーズの解決がコミットかロールバックかに関係なく、フェーズ 2 が完了するまでトランザクションリソースのロックを保持する必要があります。 Seata のアプローチは、フェーズ 1 でローカルトランザクションをコミットすることで、フェーズ 2 でのロック時間を節約し、全体的な効率を向上させることです。

<<: 分散IDとは何かを理解するのに役立つ記事

>>: クラウドコンピューティングの世界におけるデータアーキテクチャの再考