分散トランザクションの使用が推奨されないのはなぜですか?

[51CTO.com からのオリジナル記事]ビジネスの急速な発展とビジネスの複雑性の増大に伴い、ほぼすべての企業のシステムはモノリシック システムから分散システム、特にマイクロサービス アーキテクチャへと移行します。

[[433437]]

画像はBaotu.comより

すると、必然的に分散トランザクションの問題に直面することになります。この記事は分散トランザクションの解決策をまとめたものであり、皆様のお役に立てば幸いです。

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

①取引とは具体的に何ですか？

トランザクションとは何ですか?実際の例を見てみましょう。食料品店に何かを買うとき、「お金を渡し、商品を渡す」ことが取引の一例です。取引が成功したとみなされるには、支払いと配送の両方が成功する必要があります。いずれかのアクティビティが失敗した場合、トランザクションは成功したすべてのアクティビティをキャンセルします。

上記の例を理解した後、トランザクションの定義を見てみましょう。トランザクションは、さまざまな小さなアクティビティで構成される大きなアクティビティと見なすことができ、これらのアクティビティはすべて成功するか、すべて失敗します。

②まずは地元の情勢を振り返ってみましょう

コンピュータ システムでは、トランザクションはリレーショナル データベースを通じて制御されることが多く、これはデータベース自体のトランザクション特性を利用して実現されるため、データベース トランザクションと呼ばれます。

アプリケーションは主にリレーショナル データベースに依存してトランザクションを制御し、データベースは通常アプリケーションと同じサーバー上にあるため、リレーショナル データベースに基づくトランザクションはローカル トランザクションとも呼ばれます。

データベース トランザクションの 4 つの主要な特性、ACID を確認しましょう。

• A (アトミック): 原子性。トランザクションを構成するすべての操作は、完了まで実行されるか、まったく実行されないかのいずれかになります。一部の操作が成功し、他の操作が失敗することはあり得ません。
• C (一貫性): 一貫性。トランザクションの実行前と実行後にデータベースの一貫性制約に違反しません。

例: 張三は李思に100元を送金します。転送前後のデータが正確であることを一貫性と呼びます。張三が100元を送金しても李思の口座残高が100元増加しない場合は、データエラーであり、一貫性が達成されません。

• I (Isolation): 隔離。データベース内のトランザクションは通常、同時実行されます。分離とは、2 つの同時トランザクションの実行が互いに干渉せず、1 つのトランザクションが他のトランザクションの中間ステータスを確認できないことを意味します。トランザクション分離レベルを構成することで、ダーティ リードや繰り返し読み取りなどの問題を回避できます。
• D (耐久性): トランザクションが完了すると、トランザクションによってデータに加えられた変更はデータベースに保持され、ロールバックされません。

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

③分散トランザクション

銀行間送金業務は、典型的な分散型トランザクションのシナリオです。 A が銀行間で B に送金する必要がある場合、2 つの銀行のデータが関係します。転送の ACID は、データベースのローカル トランザクションでは保証できず、分散トランザクションを通じてのみ解決できます。

分散トランザクションとは、トランザクション イニシエーター、リソースとリソース マネージャー、およびトランザクション コーディネーターが分散システムの異なるノードに配置されていることを意味します。

上記の転送業務では、ユーザーA-100操作とユーザーB+100操作は同一ノード上に存在しません。

本質的に、分散トランザクションは、分散シナリオでデータ操作が正しく実行されるように設計されています。

分散環境では、分散トランザクションは、可用性、パフォーマンス、および劣化したサービスのニーズを満たすために、一貫性と分離性の要件を軽減し、一方では BASE 理論に従います (BASE 関連の理論には多くの内容が含まれており、興味のあるプログラマーは BASE 理論を参照できます)。

BASE理論:

• 基本的な可用性
• ソフトステート
• 最終的な一貫性

同様に、分散トランザクションも ACID 仕様に部分的に準拠しています。

• 原子性: 厳密に従う
• 一貫性: 取引が完了した後の一貫性は厳密に遵守されます。取引中の一貫性は適切に緩和できる
• 分離: 並列トランザクションは相互に影響を与えることができません。中間取引結果の可視性により、安全にリラックスできる
• 粘り強さ: 厳守

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

典型的なシナリオはマイクロサービス アーキテクチャです。マイクロサービスはリモート呼び出しを通じてトランザクション操作を完了します。

たとえば、注文マイクロサービスと在庫マイクロサービスの場合、注文を行うと、注文マイクロサービスは在庫マイクロサービスに在庫を減らすように要求します。つまり、JVM プロセス全体に分散トランザクションを生成します。

モノリシック システムが複数のデータベース インスタンスにアクセスする: モノリシック システムが複数のデータベース (インスタンス) にアクセスする必要がある場合、分散トランザクションが発生します。

たとえば、ユーザー情報と注文情報はそれぞれ 2 つの MySQL インスタンスに保存されます。ユーザー管理システムがユーザー情報を削除する場合、ユーザー情報とユーザーの注文情報を別々に削除する必要があります。データが異なるデータ インスタンスに分散されているため、異なるデータベース リンクを介してデータを操作する必要があり、分散トランザクションが生成されます。

つまり、データベース インスタンス間で分散トランザクションを生成します。

複数のサービスが同じデータベース インスタンスにアクセスする: たとえば、注文マイクロサービスと在庫マイクロサービスが同じデータベースにアクセスする場合でも、分散トランザクションが生成されます。その理由は、JVM プロセス全体で、2 つのマイクロサービスが異なるデータベース リンクを保持してデータベース操作を実行し、分散トランザクションを生成するためです。

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

①2PC（2相コミット）/XA

2PC (2 フェーズ コミット プロトコル)、中国語では 2 フェーズ コミットと呼ばれます。

2 フェーズ コミットは強力な一貫性設計です。 2PC は、各参加者 (各ローカル リソースとも呼ばれます) のコミットとロールバックを調整および管理するトランザクション コーディネーターの役割を導入します。 2 つのフェーズは、準備 (投票) フェーズと提出フェーズを指します。

XA は、X/Open 組織によって提案された分散トランザクション仕様です。 XA 仕様は主に、(グローバル) トランザクション マネージャー (TM) と (ローカル) リソース マネージャー (RM) 間のインターフェイスを定義します。 MySQL などのローカル データベースは、XA では RM の役割を果たします。

XA は 2 つの段階に分かれています。

• 最初のフェーズ (準備): すべての参加者 RM はトランザクションの実行を準備し、必要なリソースをロックします。参加者の準備ができたら、TM に準備ができたことを報告します。
• フェーズ 2 (コミット/ロールバック): トランザクション マネージャー (TM) は、すべての参加者 (RM) の準備ができていることを確認すると、すべての参加者にコミット コマンドを送信します。

現在、MySQL、Oracle、SQL Server、Postgre など、ほとんどの主流データベースは XA トランザクションをサポートしています。

XA トランザクションは、1 つ以上のリソース マネージャー (RM)、トランザクション マネージャー (TM)、およびアプリケーション (ApplicationProgram) で構成されます。

準備に失敗した参加者がいる場合、TM は準備を完了したすべての参加者にロールバックを通知します。

XA トランザクションの特徴は次のとおりです。

• 理解しやすく、開発も簡単
• リソースが長時間ロックされており、同時実行性が低い

②3相コミット（3PC）

3 フェーズ コミット (3PC とも呼ばれます) は、2PC に CanCommit フェーズとタイムアウト メカニズムを追加します。

一定期間内にコーディネータからコミット要求を受信しなかった場合、コミットは自動的に実行され、2PC の単一点障害の問題が解決されます。しかし、パフォーマンスと不整合の問題は根本的に解決されていません。

3段階のプロセスがどのようなものか見てみましょう。

フェーズ 1: CanCommit フェーズ。このフェーズで行われる作業は非常に単純です。コーディネーターは、トランザクションの参加者にトランザクションを完了できるかどうかを尋ねます。

両方とも「はい」と返された場合は、第 2 段階に進みます。いずれかの参加者が「いいえ」を返すか、応答の待機時間がタイムアウトすると、トランザクションは中止され、すべての参加者に中止要求が送信されます。

フェーズ 2: PreCommit フェーズ。この時点で、コーディネーターはすべての参加者に PreCommit リクエストを送信します。参加者はそれを受け取った後、トランザクション操作の実行を開始し、元に戻すおよびやり直しの情報をトランザクション ログに記録します。

参加者がトランザクション操作を完了すると（この時点ではトランザクションはコミットされていない状態です）、コミットする準備ができたことを示すためにコーディネータに「Ack」をフィードバックし、コーディネータの次の指示を待ちます。

フェーズ 3: DoCommit フェーズ。フェーズ 2 では、すべての参加ノードが PreCommit 送信を実行できる場合、コーディネーターは「事前コミット状態」から「コミット状態」に変更されます。

次に、「doCommit」リクエストがすべての参加ノードに送信されます。コミット要求を受信すると、参加ノードはそれぞれトランザクションのコミット操作を実行し、コーディネーター ノードに「Ack」メッセージをフィードバックします。コーディネーターは、すべての参加者から Ack メッセージを受信した後、トランザクションを完了します。

逆に、参加ノードの 1 つが PreCommit フィードバックを完了できなかったり、フィードバックがタイムアウトになったりすると、コーディネーターはすべての参加ノードに中止要求を送信し、トランザクションを中断します。

③サガ

Saga は、このデータベース ペーパー saga で言及されているソリューションです。基本的な考え方は、長いトランザクションを複数のローカルの短いトランザクションに分割し、それらを Saga トランザクション コーディネータが調整することです。正常に終了した場合は正常に完了します。ステップが失敗した場合、補正操作が逆の順序で 1 回呼び出されます。

上記の転送を例にとると、正常に完了した SAGA トランザクションのシーケンス図は次のようになります。

SAGA トランザクションの特徴:

• 高い同時実行性、XAトランザクションのように長時間リソースをロックする必要がない
• 通常操作と補正操作を定義する必要があり、開発の労力は XA よりも大きくなります。
• 一貫性が弱いです。送金の場合、ユーザー A が金額を差し引いたにもかかわらず、送金が失敗することがあります。

④TCC

2PC はデータベース レベルですが、TCC はビジネス レベルの分散トランザクションです。前にも述べたように、分散トランザクションにはデータベース操作だけでなく、テキスト メッセージの送信なども含まれます。ここで TCC が役立ちます。

TCC の 3 つのフェーズ:

• 試行フェーズ: 実行を試行し、すべてのビジネス チェックを完了し (一貫性)、必要なビジネス リソースを予約します (準分離)
• 確認段階: 業務チェックを行わずに、実際の業務遂行を確認します。 Try ステージで予約されたビジネス リソースのみが使用されます。確認操作にはべき等設計が必要であり、確認が失敗した後に再試行する必要があります。
• キャンセル ステージ: 実行をキャンセルし、Try ステージで予約されたビジネス リソースを解放します。保留段階のアクションを取り消すとも解釈できます。キャンセル フェーズでの例外処理ソリューションは、基本的に確認フェーズでのソリューションと同じであり、べき等設計が必要です。

上記の送金を例にとると、通常、金額は Try では凍結されますが差し引かれず、Confirm では差し引かれ、Cancel では凍結解除されます。

正常に完了した TCC トランザクションのタイミング図は次のとおりです。

TCC の機能は次のとおりです。

• 高い同時実行性、長期のリソースロックなし
• 開発量が多く、Try/Confirm/Cancelインターフェースを提供する必要がある
• 一貫性も良好で、SAGA がお金を差し引いたのに最終的に送金が失敗するといった事態は発生しません。
• TCC は、注文ベースのビジネスや中間状態に制約があるビジネスに適用できます。

⑤ローカルメッセージテーブル

ローカル メッセージ テーブルは、実際には各システムのローカル トランザクションを使用して分散トランザクションを実装します。

名前が示すように、ローカル メッセージ テーブルはローカル メッセージを格納するためのテーブルです。通常はデータベースに配置されます。業務を実行する場合、業務の実行とメッセージをメッセージテーブルに入れる操作を同じトランザクション内に配置します。これにより、メッセージがローカル テーブルに格納されたときにビジネスが正常に実行されることが保証されます。

次に次の操作を呼び出します。次の操作呼び出しが成功した場合、メッセージ テーブルのメッセージ ステータスを直接成功に変更できます。

通話が失敗しても大丈夫です。バックグラウンド タスクは、定期的にローカル メッセージ テーブルを読み取り、成功しなかったメッセージをフィルター処理して、対応するサービスを呼び出します。サービス更新が成功すると、メッセージのステータスが変更されます。

このとき、メッセージに対応する操作が成功しない可能性があるため、再試行も必要です。再試行するには、対応するサービス メソッドがべき等であることを確認する必要があります。さらに、通常、再試行回数には上限があります。最大数を超えた場合は、手動で処理するためにアラームを記録することができます。

ローカル メッセージ テーブルは実際に最終的な一貫性を実現し、一時的なデータの不整合を許容していることがわかります。

⑥メッセージ業務

RocketMQ はメッセージ トランザクションを非常に適切にサポートします。メッセージを通じてトランザクションを実装する方法を見てみましょう。

最初のステップは、トランザクション メッセージ、または半分のメッセージをブローカーに送信することです。半分のメッセージとは、メッセージが半分であるという意味ではなく、メッセージが消費者に見えないという意味です。メッセージが正常に送信された後、送信者はローカル トランザクションを実行します。次に、ローカル トランザクションの結果に基づいて、ブローカーに Commit または RollBack コマンドを送信します。

さらに、RocketMQ の送信者は、逆クエリトランザクションステータスインターフェイスを提供します。セミメッセージが一定期間内に操作要求を受信しない場合、ブローカーはリバース クエリ インターフェイスを使用して送信者のトランザクションが正常に実行されたかどうかを確認し、Commit コマンドまたは RollBack コマンドを実行します。

コミットの場合、サブスクライバーはメッセージを受信して​​から、対応する操作を実行します。完了後、サブスクライバーはメッセージを消費できます。

RollBack の場合、サブスクライバーはメッセージを受信せず、トランザクションが実行されていないことを意味します。 RocketMQ を使用すると比較的簡単に実装できることがわかります。 RocketMQ はトランザクション メッセージの機能を提供します。トランザクション逆クエリ インターフェイスを定義するだけで済みます。

同時に、メッセージ トランザクションでも最終的な一貫性が実現されていることもわかります。

⑦ベストエフォート通知

通知の発信者は、特定のメカニズムを使用して、ビジネス処理の結果を受信者に通知するために最大限の努力を払います。

具体的には以下が含まれます:

• 特定のメッセージ繰り返し通知メカニズムがあります。通知の受信者が通知を受け取っていない可能性があるため、メッセージを繰り返すための特定のメカニズムが必要です。
• メッセージ校正メカニズム。最善の努力にもかかわらず受信者に通知されない場合、または受信者がメッセージを消費した後に再度消費する必要がある場合、受信者は要求を満たすために通知側にメッセージ情報を積極的に問い合わせることができます。

先ほど紹介したローカル メッセージ テーブルとメッセージ トランザクションは、どちらも信頼できるメッセージです。ここで紹介したベストエフォート通知とどう違うのでしょうか?

信頼性の高いメッセージの一貫性: 通知を開始する側は、メッセージが送信され、通知を受信する側に確実に送信されるようにする必要があります。メッセージの信頼性は主に通知を開始する側によって保証されます。

ベスト エフォート通知: 通知の発信者は、通知の受信者にビジネス処理の結果を通知するために最善の努力を払いますが、メッセージが受信されない可能性があります。この場合、通知の受信者は、ビジネス処理の結果を照会するために、イニシエーターのインターフェースを積極的に呼び出す必要があります。通知の信頼性は通知の受信者によって異なります。

解決策としては、ベストエフォート通知には以下が必要です。

• 通知受信者がインターフェースを通じて業務処理結果を照会できるようにインターフェースを提供する
• メッセージ キュー ACK メカニズムは、通知に必要な時間ウィンドウの上限に達するまで、通知間隔を 1 分、5 分、10 分、30 分、1 時間、2 時間、5 時間、10 時間と徐々に増やします。通知はもうありません

ベスト エフォート通知は、ビジネス通知タイプに適用されます。たとえば、WeChat トランザクションの結果は、コールバック通知やトランザクション クエリ インターフェイスを含むベスト エフォート通知を通じて各販売者に通知されます。

⑧AT取引モード

これは、Alibaba のオープンソース プロジェクト Seata のトランザクション モードであり、Ant Financial では FMT とも呼ばれます。利点は、トランザクション モードが XA モードと同様に使用されることです。企業はさまざまな補償操作を記述する必要はなく、ロールバックはフレームワークによって自動的に完了します。欠点も AT と同様で、ロック時間が長く、高同時実行シナリオを満たしません。

Seata プロジェクトでは、Alibaba ミドルウェアによって初めてオープンソース化された AT モード (自動トランザクション) は、革新的でビジネスに影響を与えない分散トランザクション ソリューションです。

Seata の GA バージョンのリリース以降、AT モードはオープンソース コミュニティで広く注目を集めており、多くの企業ユーザーが Seata の AT モードを本番環境に適用しています。

AT モード ステージ 1: まず、Seata のコンポーネントで分散トランザクションを有効にする場合は、ビジネス エントリまたはトランザクション開始エントリに @GlobalTransactional アノテーションを追加する必要があります。

AT モードの場合は、データ ソース プロキシ (seata1.0 以降では自動プロキシが完全にサポートされています) を設定し、それを sqlsessionfactroy で使用する必要があります (または、プロキシされたデータ ソースを直接の JDBC 操作に使用します)。

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

AT モードの 2 フェーズ コミット: 2 番目のフェーズがコミットされると、最初のフェーズで「ビジネス SQL」がデータベースに送信されているため、Seata フレームワークは、最初のフェーズで保存されたスナップショット データと行ロックを削除するだけで、データのクリーンアップを完了できます。

AT モード 2 段階ロールバック: 2 段階目をロールバックする場合、Seata は 1 段階目で実行した「業務 SQL」をロールバックし、業務データを復元する必要があります。

ロールバック方式は、「以前のイメージ」を使用してビジネス データを復元することです。ただし、復元する前に、まずダーティ ライトを検証し、「データベースの現在のビジネス データ」と「後のイメージ」を比較する必要があります。

2 つのデータ コピーが完全に一致している場合は、ダーティ ライトがなく、ビジネス データを復元できることを意味します。矛盾がある場合は、ダーティ ライトが発生しており、ダーティ ライトを手動で処理する必要があることを意味します。

まとめ

この記事では、分散トランザクションの基本的な理論をいくつか紹介し、一般的に使用される分散トランザクション ソリューションについて説明します。

分散トランザクションはそれ自体が技術的な課題であり、ビジネスで使用する特定のソリューションは、さまざまなビジネス特性に応じて選択する必要があります。

しかし、分散トランザクションによってプロセスの複雑さが大幅に増加し、余分なオーバーヘッド作業が大量に発生することもわかりました。 「コード量が増え、業務が複雑化し、パフォーマンスが低下しました。」

したがって、実際に開発する際には、可能であれば分散トランザクションを使用しないようにする必要があります。

著者: JackHu

紹介：水地健康インフラの上級技術専門家

編集者：タオ・ジアロン

論文募集: 論文の提出や掲載を希望する技術者の方は [email protected] までご連絡ください。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]