「分散トランザクション」がまだ理解できませんか?この記事ではわかりやすく解説します！

[51CTO.com からのオリジナル記事] この記事では、分散トランザクションとは何か、分散トランザクションが解決する問題、分散トランザクションを実装する際の難しさ、解決策、さまざまなシナリオでの解決策の選択を紹介し、図表を通じて整理、要約、比較します。

[[252091]]

この記事をじっくり読んでいただければ、分散トランザクションについて語るときに、「2PC」、「3PC」、「MQ メッセージ トランザクション」、「結果整合性」、「TCC」などの断片的な知識だけではなく、知識を 1 つにつなげて知識体系を形成できると思います。

取引とは何か

分散トランザクションを紹介する前に、まずトランザクションとは何かを紹介しましょう。

取引の具体的な定義

トランザクションは、アクティビティに関係するすべての操作を分割できない実行単位に組み込むメカニズムを提供します。トランザクションを構成するすべての操作は、すべての操作が正常に実行できる場合にのみコミットできます。いずれかの操作の実行に失敗した場合、トランザクション全体がロールバックされます。

簡単に言えば、トランザクションは「すべてか無か」のメカニズムを提供します。

データベーストランザクションのACID特性

トランザクションはデータに基づく操作であり、通常はトランザクション データがデータベースに保存されるようにする必要があります。したがって、トランザクションを導入するときは、データベース トランザクションの ACID 特性を導入する必要があります。

ACID は、データベース トランザクションを正しく実行するための 4 つの基本特性の略語です。

原子性

トランザクション全体のすべての操作は完了するか、まったく完了しないかのいずれかであり、途中のリンクで停止することは不可能です。

トランザクションの実行中にエラーが発生した場合、トランザクションが実行されなかったかのように、トランザクション開始前の状態にロールバックされます。

たとえば、口座 A から口座 B に 100 元を振り込む銀行振込は、次の 2 つの手順に分かれています。

• 口座Aから100元を引き出します。
• 口座Bに100元を入金します。

これら 2 つの手順は、一緒に完了するか、または完了しないかのいずれかである必要があります。最初のステップのみを完了し、2 番目のステップに失敗すると、不可解なことに 100 元を失うことになります。

一貫性

トランザクションの開始前およびトランザクションの終了後、データベース データの一貫性制約は違反されません。

たとえば、既存の整合性制約 A+B=100 があるとします。トランザクションが A を変更する場合、トランザクション終了後も A+B=100 が満たされるように B を変更する必要があります。そうしないと、トランザクションは失敗します。

分離

データベースでは、複数の同時トランザクションが同時にデータを読み取り、書き込み、変更することができます。あるトランザクションによってアクセスされるデータが別のトランザクションによって変更されている場合、他のトランザクションがコミットされない限り、そのトランザクションによってアクセスされるデータはコミットされていないトランザクションの影響を受けません。

分離により、複数のトランザクションが同時に実行されるときに、相互実行によって発生するデータの不整合を防ぐことができます。

たとえば、口座 A から口座 B に 100 元を送金する取引があるとします。取引が完了する前に B が自分の口座を照会しても、新しく追加された 100 元は表示されません。

耐久性

トランザクションが完了すると、データの変更は永続的になり、システムに障害が発生しても失われることはありません。

簡単に言えば、ACID はさまざまな次元からのトランザクションの特性を表します。

• 原子性: トランザクション操作の整合性。
• 一貫性: トランザクション操作におけるデータの正確性。
• 分離: 同時トランザクション操作におけるデータの正確性。
• 耐久性: トランザクションによるデータ変更の信頼性。

トランザクションをサポートするデータベースには、次の 4 つの特性が必要です。そうしないと、トランザクション処理中にデータの正確性が保証されず、処理結果が要求者の要件を満たさない可能性があります。

データベーストランザクションを使用する場合

トランザクションの基本的な概念を紹介した後、データベース トランザクションはいつ使用すればよいのでしょうか。

簡単に言えば、ビジネスには一連のデータ操作が存在します。いずれかの操作が失敗した場合、操作セット全体は実行されず、未実行の状態に復元されます。すべての操作が成功するか、すべての操作が失敗します。

データベース トランザクションを使用する場合は、トランザクションをできるだけ短くするように注意する必要があります。複数の異なるテーブルのデータを変更する長時間のトランザクションは、システム内の他のすべてのユーザーに重大な支障をきたし、パフォーマンスの問題を引き起こす可能性があります。

2. 分散トランザクションとは何か

トランザクションに関する基本的な概念を紹介した後、分散トランザクションについて説明します。

分散型発電の背景と概念

インターネットの急速な発展に伴い、マイクロサービスや SOA などのサービス アーキテクチャ モデルが大規模に使用されるようになりました。現在、分散システムは一般的に複数の独立したサブシステムで構成されており、複数のサブシステムがネットワーク通信を通じて相互に連携してさまざまな機能を実行します。

完了するために複数のサブシステムにまたがるユースケースは多数あります。典型的な例としては、少なくとも取引システムと支払いシステムが含まれる電子商取引 Web サイトの注文および支払いプロセスがあります。

さらに、このプロセスにはトランザクションの概念が含まれており、トランザクション システムと支払いシステム間のデータの一貫性を確保します。ここでは、このシステム間トランザクションを分散トランザクションと呼びます。

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

一般的に普及しているインターネット取引ビジネスを例に挙げてみましょう。

上の図には、在庫と注文という 2 つの独立したマイクロサービスが含まれています。各マイクロサービスは独自のデータベースを維持します。

トランザクション システムのビジネス ロジックでは、製品を注文する前に、まず在庫サービスを呼び出して在庫を減算し、次に注文サービスを呼び出して注文レコードを作成する必要があります。

複数のデータベース間のデータ更新がトランザクションによって保証されない場合、サブシステム データの不整合やビジネス上の問題が発生することがわかります。

分散トランザクションの難しさ

トランザクションの原子性

トランザクション操作は異なるノードにまたがります。複数のノードのうちの 1 つでの操作が失敗した場合、何もしないか、セット全体を実行するか (All or Nothing) のいずれかで、複数ノードの操作のアトミック性を確保する必要があります。

トランザクションの一貫性

ネットワーク伝送障害またはノード障害が発生すると、ノード間のデータ複製チャネルが中断されます。トランザクション操作を実行するときは、トランザクション操作によってデータがデータベースで定義された制約、トリガー、およびその他のルールに違反することがないように、データの一貫性を確保する必要があります。

トランザクション分離

トランザクション分離の本質は、複数の同時トランザクション間での読み取りと書き込みの競合および書き込みと書き込みの競合を正しく処理する方法です。分散トランザクション制御では、非同期コミットが発生する可能性があり、このとき「部分的にコミットされた」トランザクションが出現する可能性があるためです。

この時点でデータにアクセスする同時アプリケーションが制御されていない場合、「ダーティ リード」の問題が発生する可能性があります。

3. 分散システムの一貫性

上記で紹介した分散トランザクションの難しさには、最終的にデータの不整合につながる問題が伴います。以下では、分散システムの一貫性の問題を理論的に分析し、これらの理論に基づいて分散ソリューションを紹介します。

可用性と一貫性の矛盾: CAP定理

CAP 定理はブリューワーの定理とも呼ばれ、カリフォルニア大学のコンピューター科学者ブリューワーによって 2000 年に提唱された仮説です。

2002 年、MIT のセス・ギルバートとナンシー・リンチがブリューワーの予想の証明を発表し、ブリューワーの予想は分散コンピューティングの分野で認められた定理となりました。

ブリューワーが CAP 予想を提唱したとき、一貫性、可用性、分断耐性という 3 つの単語の意味を具体的に定義しておらず、具体的な定義は資料によって異なります。

より分かりやすく説明するために、Robert Greiner 氏の記事「CAP 定理」を参考にしてみましょう。

• http://robertgreiner.com/about/
• http://robertgreiner.com/2014/08/cap-theorem-revisited/

CAP理論の定義

分散システム (相互接続され、データを共有するノードの集合) では、読み取りおよび書き込み操作に関して、一貫性、可用性、およびパーティション耐性の 3 つのうち 2 つしか保証できず、残りの 1 つは犠牲にする必要があります。

一貫性、可用性、およびパーティション耐性の具体的な説明は次のとおりです。

C - 一貫性:読み取りでは、特定のクライアントの最新の書き込みが返されることが保証されます。

特定のクライアントの場合、読み取り操作は正しい書き込み操作結果を返すことが保証されます。

ここで強調したいのは、同じデータが同時に存在するということではありません。システムがトランザクションを実行する場合、トランザクション実行プロセス中、システムは実際には不整合な状態にあり、異なるノード上のデータは完全には整合していません。

一貫性は、トランザクションの実行中にクライアントがコミットされていないデータを読み取ることができないため、クライアントの読み取り操作で最新の書き込み操作の結果を取得できることを強調します。

トランザクションがコミットされた後にのみ、クライアントはトランザクションによって書き込まれたデータを読み取ることができます。トランザクションが失敗した場合、トランザクションはロールバックされ、クライアントはトランザクションの途中で書き込まれたデータを読み取ることができません。

A - 可用性:障害のないノードは、妥当な時間内に妥当な応答を返します (エラーやタイムアウトはありません)。

障害のないノードは、妥当な時間内に妥当な応答 (エラーやタイムアウトではない) を返します。

ここで強調されているのは、適切な応答、タイムアウトなし、エラーなしです。 「正しい」結果が何であるかは述べられていないことに注意してください。たとえば、100 が返されるはずなのに実際には 90 が返された場合、それは間違いなく正しい結果ではありませんが、妥当な結果である可能性があります。

P - パーティション耐性 パーティション耐性:ネットワーク パーティションが発生してもシステムは機能し続けます。

ネットワークパーティションが発生しても、システムは「その役割を実行」し続けることができます。

ここでのネットワーク分割とは、分散システムにおいて、ノードで構成されるネットワークを接続する必要があることを意味します。

しかし、何らかの障害（ノード間のネットワーク接続が切断される、ノードがクラッシュする）により、一部のノードが切断され、ネットワーク全体が複数の領域に分割され、これらの切断された領域にデータが散在します。

一貫性、可用性、およびパーティション許容度の選択肢

CAP 理論では、3 つの要素のうち 2 つしか選択できないと定義されていますが、分散環境で考えると、ネットワーク自体が 100% 信頼できるわけではなく、障害が発生する可能性があるため、分割は避けられない現象であるため、P (分割許容度) 要素を選択する必要があることがわかります。

CA (一貫性 + 可用性) を選択し、P (パーティション耐性) を放棄すると、パーティションが発生したときに、C (一貫性) を確保するために、システムは書き込みを禁止する必要があります。

書き込み要求がある場合、システムはエラーを返します (たとえば、現在のシステムでは書き込みが許可されていません)。これは、A (可用性) ではエラーなし、タイムアウトなしの戻りが要求されるため、A (可用性) と競合します。

したがって、理論上、分散システムでは CA (一貫性 + 可用性) アーキテクチャを選択することは不可能です。一貫性と可用性の間で妥協しながら、CP (一貫性 + パーティション許容度) または AP (可用性 + パーティション許容度) アーキテクチャのみを選択できます。

①CP - 一貫性 + パーティション耐性

上図に示すように、Node1 と Node2 間の接続が中断されるため、パーティション現象が発生します。 Node1 のデータは y に更新されましたが、Node1 と Node2 間のレプリケーション チャネルが中断され、データ y を Node2 に同期できません。 Node2 上のデータは依然として古いデータ x のままです。

このとき、クライアント C が Node2 にアクセスすると、Node2 はクライアントに「現在、システムでエラーが発生しました」と知らせるためにエラーを返す必要があります。この処理方法は可用性の要件に違反するため、CAP は CP のみを満たすことができます。

②AP - 可用性 + 分断耐性

Node2 上のデータは依然として古いデータ x のままです。クライアント C が Node2 にアクセスすると、Node2 は所有する現在のデータ x をクライアントに返します。

実際、現在の最新データはすでに y であり、一貫性の要件を満たしていません。したがって、CAP は AP のみを満たすことができます。

注:ここで Node2 は x を返しますが、これは「正しい」結果ではなく「妥当な」結果です。x は古いデータであり、乱れた値ではなく、最新のデータではないためです。

CAP 理論によれば、分散システムは AP または CP しか選択できないとされていますが、実際にはシステム全体が AP または CP しか選択できないという意味ではないことも付け加えておく価値があります。

CAP 理論を実装する場合、システム全体のすべてのデータを同じ戦略に直接制限するのではなく、さまざまなアプリケーション シナリオと要件に応じてシステム内のデータを分類し、データの種類ごとに異なる戦略 (CP または AP) を選択する必要があります。

また、CP または AP しか選択できないということは、システムにパーティションが発生した場合に、C (一貫性) と A (可用性) の両方を同時に保証できないことを意味します。しかし、これは何もすべきではないという意味ではありません。パーティション障害が解決された後も、システムは CA を維持する必要があります。

CAP理論の拡張：BASE理論

BASE は、Basically Available (基本的に利用可能)、Soft State (ソフト ステート)、Eventual Consistency (最終的な一貫性) の略です。

その中心的な考え方は、強力な一貫性を実現できない場合でも (CAP 一貫性は強力な一貫性です)、アプリケーションは適切な方法を使用して最終的な一貫性を実現できるというものです。

BA - 基本的に利用可能

分散システムに障害が発生した場合、コアが利用可能であることを保証するため、ある程度の可用性が失われることが許容されます。

ここでのキーワードは「部分」と「コア」です。実際には、具体的な事業に応じて、どれがコアとなるかを検討する必要があります。

たとえば、ログイン機能は登録機能よりもコアな機能です。登録に失敗すると、せいぜい一部のユーザーが失われることになります。ユーザーが登録しているのにログインできない場合、そのユーザーはシステムを使用できないことになり、影響はより広範囲に及びます。

S - ソフトステート

システム全体の可用性に影響を与えることなく、システムは中間状態をとることができます。ここでの中間状態は、CAP 理論におけるデータの不整合です。

E — 最終的な一貫性

一定期間が経過すると、システム内のすべてのデータ コピーが最終的に一貫した状態になります。

ここでのキーワードは「ある時期」と「最終的に」です。 「ある時間」はデータの特性と大きく関係します。異なるビジネスや異なるデータでは、異なる不整合な期間を許容できます。

たとえば、決済サービスでは、ユーザーが常に注目しているため、数秒以内の一貫性が求められます。有名人のWeibo投稿は、短期間で有名人のWeibo投稿を見ることができなければユーザーがそれに気づかないため、30分以内に一貫した状態に達するまで許容されます。

「最終的に」の意味は、どれだけ時間がかかっても、最終的には一貫した状態に到達するということです。

BASE 理論は本質的に CAP の拡張および補足です。より具体的には、CAP の AP スキームを補足するものです。CAP理論では遅延は無視されますが、実際のアプリケーションでは遅延は避けられません。

これは、完璧な CP シナリオが存在しないことを意味します。たとえ数ミリ秒のデータ複製遅延があったとしても、システムはこの数ミリ秒の時間間隔内で CP 要件を満たしません。

したがって、CAP の CP スキームは実際には最終的な一貫性も実現しますが、「特定の時間」は数ミリ秒のみを指します。

AP スキームは、一貫性を永久に放棄するのではなく、パーティション障害の期間中のみ一貫性を犠牲にします。

これは実際には BASE 理論の拡張です。パーティション分割中は一貫性が犠牲になりますが、パーティション障害が回復した後、システムは最終的な一貫性を実現する必要があります。

データ一貫性モデル

先ほど紹介した BASE モデルでは、「強い一貫性」と「最終的な一貫性」について言及しました。以下では、これらの一貫性モデルについて紹介します。

分散システムは、データを複製し、異なるマシンにデータの異なるコピーを保存することで、システムの信頼性と耐障害性を向上させます。データ コピーの一貫性を維持するにはコストがかかるため、多くのシステムでは弱い一貫性を使用してパフォーマンスを向上させます。

一般的な一貫性モデルは次のとおりです。

強力な一貫性:どのデータ コピーに対して更新操作が実行されても、その後のすべての読み取り操作で最新のデータを取得できる必要があります。

単一コピーデータの場合、読み取り操作と書き込み操作は同じデータに対して実行されるため、強力な一貫性を簡単に確保できます。データの複数のコピーには、分散トランザクション プロトコルが必要です。

弱い一貫性:この一貫性では、ユーザーがシステム内の特定のデータに対する特定の操作の更新を読み取るのに時間がかかります。この期間を「不一致ウィンドウ」と呼びます。

結果的一貫性:弱い一貫性の特殊なケースです。この一貫性により、システムは、ユーザーがシステム内の特定のデータに対する特定の操作の更新を最終的に読み取ることができることを保証します (読み取り操作の前にデータに対する他の更新操作はありません)。

「不整合ウィンドウ」のサイズは、相互作用の遅延、システム負荷、およびデータコピーの数によって異なります。

システムが選択する一貫性モデルは、アプリケーションの一貫性要件によって異なります。選択された整合性モデルは、システムがユーザー要求を処理する方法やレプリカ保守テクノロジの選択にも影響します。

次のセクションでは、上記の一貫性モデルに基づいた分散トランザクションのソリューションを紹介します。

柔軟な対応

柔軟な取引の概念

電子商取引などのインターネット シナリオでは、従来のトランザクションによってデータベースのパフォーマンスと処理機能にボトルネックが生じます。分散分野では、CAP理論やBASE理論に基づいて、柔軟なトランザクションの概念を提案する人もいます。

BASE 理論の設計思想に基づき、柔軟なトランザクションの下で、システム全体の可用性 (Basically Available) に影響を与えることなく、システムは不整合なデータを持つ中間状態 (Soft State) を持つことが許可されます。データ同期の遅延後、最終データは一貫性を保つことができます。

ACID を完全に放棄するわけではありませんが、一貫性の要件を緩和し、ローカル トランザクションを使用することで、究極の分散トランザクション一貫性を実現しながら、システム スループットも確保します。

柔軟なトランザクションのいくつかの機能の実装

以下は、柔軟なトランザクションを実装するための一般的な機能です。ソリューションによって要件が異なるため、特定のソリューションではこれらの機能がすべて満たされない場合があります。

可視性（外部からクエリ可能） ：分散トランザクションの実行中に、特定のステップでエラーが発生した場合、他のいくつかの操作の処理状況を明確に把握する必要があります。これには、クエリを通じて操作の処理ステータスを判断できるように、他のサービスがクエリ インターフェイスを提供する必要があります。

操作が検索可能であることを保証するには、各サービスへの各呼び出しにグローバルに一意の識別子が必要です。この識別子は、ビジネス ドキュメント番号 (注文番号など) またはシステムによって割り当てられた操作シリアル番号 (支払い記録シリアル番号など) にすることができます。さらに、操作の時間情報も完全に記録する必要があります。

演算のべき等性:べき等性は実際には数学的な概念です。べき等関数またはべき等メソッドは、同じパラメータで繰り返し実行して同じ結果を生成することができる関数です。

べき等操作の特徴は、複数回の実行の影響が 1 回の実行の影響と同じであることです。つまり、同じメソッドを同じパラメータで複数回呼び出すことで、1 回の呼び出しと同じビジネス結果を生み出すことができます。

操作の冪等性が必要な理由は、データの最終的な一貫性を保証するために、多くのトランザクション プロトコルで多くの再試行操作が必要になるためです。メソッドがべき等性を保証しない場合は、再試行できません。

システム内のすべてのリクエストと処理結果をキャッシュしたり、繰り返し操作を検出した後、最後の処理結果を直接返したりするなど、べき等操作を実装する方法は多数あります。

4. 一般的な分散トランザクションソリューション

分散システムの一貫性関連の理論を紹介した後、さまざまな一貫性モデルに基づく分散トランザクションの一般的なソリューションを紹介し、各ソリューションの使用シナリオを紹介します。

分散トランザクションを実装する方法は多数ありますが、最も古典的な方法は、Tuxedo が提案する XA 分散トランザクション プロトコルです。 XA プロトコルには、2 フェーズ コミット (2PC) と 3 フェーズ コミット (3PC) の 2 つの実装が含まれます。

2PC（2フェーズコミット）ソリューション：強力な一貫性

ソリューションの概要

2 フェーズ コミット プロトコル (2PC) は、一般的に使用される分散トランザクション ソリューションであり、トランザクション送信プロセスを準備フェーズと送信フェーズの 2 つのフェーズに分割します。トランザクションの開始者はコーディネーターと呼ばれ、トランザクションの実行者は参加者と呼ばれます。

分散システムでは、各ノードは自身の操作の成功または失敗を知ることができますが、他のノードの操作の成功または失敗を知ることはできません。

トランザクションが複数のノードにまたがる場合、トランザクションの原子性と一貫性を維持するために、参加者全員の操作結果を統一的に制御し、操作結果を実際にコミットするかロールバックするかを指示するコーディネータが導入されます。

2 フェーズ コミットのアルゴリズムの考え方は、次のように要約できます。参加者はコーディネータに操作の成功または失敗を通知し、コーディネータはすべての参加者のフィードバック情報に基づいて、各参加者が操作を送信するか、操作を終了するかを決定します。

基本的な考え方は、各トランザクションに対して try-before-commit アプローチを使用することです。処理後、すべての読み取り操作で最新のデータを取得できる必要があります。したがって、2 フェーズ コミットは強力な一貫性アルゴリズムと見なすこともできます。

処理フロー

簡単に言えば、コーディネーターノードはリーダーに例えられ、参加者はフォロワーに例えられます。リーダーはフォロワーによるタスクの実行を調整します。

フェーズ1: 準備

準備フェーズには 3 つのステップがあります。

• コーディネーターは、トランザクションの内容をすべての参加者に送信し、トランザクションを送信できるかどうかを尋ね、すべての参加者からの応答を待ちます。
• 各参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。
• 参加者が正常に実行した場合、コーディネータに「はい」というフィードバックを与え、送信できることを意味します。実行が失敗した場合、コーディネータに「いいえ」というフィードバックが返され、送信できないことを意味します。

フェーズ2: 提出フェーズ

コーディネータが参加者から失敗メッセージまたはタイムアウトを受信した場合、各参加者にロールバックメッセージを直接送信します。それ以外の場合は、コミット メッセージを送信します。

参加者はコーディネータの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理プロセスで使用されるすべてのロック リソースを解放します。 (注: ロック リソースは *** フェーズで解放する必要があります) 次に、送信フェーズのプロセスを 2 つの状況で説明します。

ケース 1: すべての参加者が「はい」と応答すると、上の図に示すように、トランザクションがコミットされます。

• コーディネーターは、すべての参加者にトランザクションを送信する正式なリクエスト（コミット リクエスト）を送信します。
• 参加者はコミット要求を実行し、トランザクション全体で占有されていたリソースを解放します。
• 各参加者は、完了の ack (確認応答) メッセージをコーディネータにフィードバックします。
• コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションがコミットされます。

ケース 2: フェーズ 1 の参加者のいずれかが「いいえ」と応答すると、上の図に示すように、トランザクションは終了します。

• コーディネーターはすべての参加者にロールバック要求を送信します。
• 参加者はフェーズ 1 の元に戻す情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。
• 各参加者は、コーディネータに ack 完了メッセージをフィードバックします。
• コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションは中断されます。

ソリューションの概要

2PC ソリューションは実装が簡単ですが、主に次の問題のため、実際のプロジェクトではほとんど使用されません。

• パフォーマンスの問題:トランザクションの送信フェーズ中、すべての参加者は同期ブロック状態になり、システム リソースを占有し、パフォーマンスのボトルネックが発生しやすくなります。
• 信頼性の問題:コーディネータに単一障害点の問題がある場合、コーディネータに障害が発生すると、参加者はロックされた状態のままになります。
• データ整合性の問題:フェーズ 2 でローカル ネットワークの問題が発生すると、一部のトランザクション参加者はコミット メッセージを受信しますが、他のトランザクション参加者はコミット メッセージを受信しないため、ノード間でデータの不整合が発生します。

3PC（3相コミット）ソリューション

ソリューションの概要

3 フェーズ コミット プロトコルは、2 フェーズ コミット プロトコルの改良版です。 2 フェーズ コミット プロトコルとは異なり、タイムアウト メカニズムが導入されています。同時に、コーディネーターと参加者の両方にタイムアウト メカニズムが導入されます。

3 フェーズ コミットでは、第 2 フェーズの準備フェーズを 2 つのフェーズに分割し、preCommit フェーズを挿入します。これにより、準備後に参加者が「不確実な状態」になり、コーディネータのクラッシュやエラーのためにコミットするか中止するかがわからないという、2 フェーズ コミットで潜在的に長い遅延が発生する問題が解決されます。

処理フロー

フェーズ 1: canCommit

コーディネーターは参加者にコミット要求を送信します。参加者がコミットできる場合は、 yes 応答 (参加者はトランザクション操作を実行しません) を返し、そうでない場合は no 応答を返します。

• コーディネーターは、トランザクションの内容を含む canCommit リクエストをすべての参加者に送信し、トランザクションをコミットできるかどうかを尋ね、すべての参加者からの応答を待ちます。
• canCommit リクエストを受信した後、参加者はトランザクション操作が実行できると判断した場合は yes をフィードバックして準備状態に入り、そうでない場合は no をフィードバックします。

フェーズ2: preCommit

コーディネーターは、フェーズ 1 の canCommit 参加者の応答に基づいて、トランザクション ベースの preCommit 操作を実行するかどうかを決定します。応答に応じて 2 つの可能性があります。

ケース 1: フェーズ 1 では、すべての参加者が「はい」と応答し、上の図に示すように、参加者はトランザクションを事前実行します。

• コーディネーターはすべての参加者に preCommit リクエストを送信し、準備フェーズに入ります。
• preCommit 要求を受信した後、参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。
• 各参加者は、コーディネータに ack 応答または no 応答をフィードバックし、最終指示を待ちます。

ケース 2: フェーズ 1 で、いずれかの参加者が「いいえ」と応答するか、コーディネーターが待機タイムアウト後にすべての参加者からのフィードバックを受信できず、上の図に示すようにトランザクションが中止されます。

• コーディネーターはすべての参加者に中止要求を送信します。
• 参加者は、コーディネータから中止要求を受信するか、コーディネータからの要求を待機中にタイムアウトが発生すると、トランザクションを中止します。

フェーズ3: コミットする

このフェーズは実際のトランザクションがコミットされるフェーズであり、次の 2 つの状況に分けられます。

ケース 1: フェーズ 2 では、上図に示すように、すべての参加者が ack で応答し、実際のトランザクション コミットを実行します。

• コーディネーターが作業状態の場合、すべての参加者にコミット要求を送信します。
• do Commit リクエストを受信した後、参加者はトランザクションのコミットを正式に実行し、トランザクション全体で占有されていたリソースを解放します。
• 各参加者は、コーディネータに ack 完了メッセージをフィードバックします。
• コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションがコミットされます。

ケース 2: フェーズ 2 では、いずれかの参加者が「いいえ」と応答するか、コーディネーターが待機タイムアウト後にすべての参加者からのフィードバックを受信できず、上の図に示すようにトランザクションが中止されます。

• コーディネーターが作業状態にある場合は、すべての参加者に中止要求を送信します。
• 参加者はフェーズ 1 の元に戻す情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。
• 各参加者は、コーディネータに ack 完了メッセージをフィードバックします。
• コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションは中断されます。

注: フェーズ 3 に入った後は、コーディネータに問題があるか、コーディネータと参加者間のネットワークに問題があるかに関係なく、参加者はコーディネータから送信されたコミット要求または中止要求を受信できなくなります。この時点で、すべての参加者はタイムアウトを待った後、トランザクションの送信を続行します。

ソリューションの概要

利点: 2 フェーズ コミットと比較して、3 フェーズ コミットではブロックの範囲が縮小され、コーディネーターまたは参加者は待機タイムアウト後にトランザクションを中断します。コーディネータの単一ポイントの問題は回避されます。フェーズ 3 でコーディネーターに問題が発生した場合、参加者はトランザクションの送信を継続します。

デメリット:データの不整合が依然として存在します。参加者が事前にコミットのリクエストを受け取り、DOコミット命令を待つと、コーディネーターがトランザクションを中断するよう要求し、コーディネーターが参加者と正常に通信できない場合、参加者は引き続き取引をコミットし、データの矛盾が生じます。

TCCトランザクション：最終的な一貫性

解決策の概要

TCC（Try-Confirm-Cancel）の概念は、2007年に公開された「Life Beyond Distributed Transactions：An Apostateの意見」というタイトルの論文で、Pat Hellandによって最初に提案されました。

TCCは、サービス指向の2段階プログラミングモデルであり、その3つの方法である試行、確認、キャンセルはすべて、ビジネスコーディングによって実装されています。

• フェーズとして、TRY操作はリソースのチェックと予約を担当します。
• 確認操作は、実際のビジネスを実行する2フェーズのコミット操作です。
• キャンセルは予約されたリソースをキャンセルします。

TCCトランザクションの試行、確認、キャンセルは、SQLトランザクションのロック、コミット、ロールバックとして理解できます。

処理フロー

理解しやすくするために、例としてeコマース順序を使用して、次のソリューションを分析します。ここでは、プロセス全体が単純に2つのステップに分割されます。在庫を差し引き、注文の作成です。在庫サービスと注文サービスは、異なるサーバーノード上にあります。

tryステージ

実行段階から、ビジネスロジックは従来のトランザクションメカニズムと同じです。しかし、ビジネスの観点からは、それは違います。

TCCメカニズムの試行は、予備操作にすぎません。それとその後の確認は、まったく完全なビジネスロジックを形成することができます。この段階は主に完了します：

• すべてのビジネスチェック（一貫性）が完了します。
• 必要なビジネスリソース（準分離）を予約します。
• 操作を実行してみてください。

TCCトランザクションメカニズムは、初期操作（TRY）を中心にしており、確認操作（確認）とキャンセル操作（キャンセル）の両方が初期操作（TRY）を中心に展開します。

したがって、TRYフェーズでの操作は完全に安全です。たとえ故障しても、実行結果を取り消すためのキャンセル操作がまだあります。

製品在庫は100で、購入数量が2であると仮定します。ここでは、在庫の確認と更新中に、ユーザーの購入数量の在庫が凍結され、注文が同時に作成され、注文ステータスは確認が保留されています。

inconfirm /キャンセルステージ

TRYフェーズのすべてのサービスが正常に実行されるかどうかに応じて、確認操作（確認）またはキャンセル操作（キャンセル）を実行し続けます。

操作の確認とキャンセルは、iDempotencyを満たしています。確認またはキャンセルの操作が失敗した場合、実行が完了するまで再試行されます。

確認：TRYフェーズのすべてのサービスが正常に実行されたら、確認ビジネスロジック操作を実行します

ここで使用されるリソースは、TRYフェーズで予約されているビジネスリソースでなければなりません。 TCCトランザクションメカニズムでは、リソースが通常のフェーズで正常に予約できる場合、確認を完全かつ正しく提出できると考えられています。

確認段階は、Try段階の補足としても見ることができます。完全なビジネスロジックを形成することを一緒に試してみてください。

キャンセル：TRYフェーズでサービスが実行に失敗すると、キャンセルフェーズが入力されます。

キャンセルは実行をキャンセルし、トライステージで予約されたビジネスリソースをリリースします。上記の例では、キャンセル操作は凍結在庫をリリースし、注文ステータスを更新してキャンセルします。

ソリューションの概要

従来のトランザクションメカニズム（X/Open XA）と比較して、TCCトランザクションメカニズムには、上記のXAトランザクションメカニズムよりも次の利点があります。

• パフォーマンスの改善：特定のビジネスによって制御されるリソースロックの粒度は小さくなり、リソース全体がロックされません。
• 最終的なデータの一貫性：確認とキャンセルの実装に基づいて、トランザクションが最終的に確認またはキャンセルされることが保証され、データの一貫性が確保されます。
• 信頼性： XAプロトコルのコーディネーターの単一点障害問題が解決されます。ビジネス活動全体が主要なビジネスパーティーによって開始および管理され、ビジネスアクティビティマネージャーもマルチポイントになり、クラスターを導入します。

短所： TCCの試行、確認、およびキャンセル操作機能は、特定のビジネスに従って実装する必要があり、その結果、高度なビジネス結合と開発コストが増加します。

ローカルメッセージテーブル：最終的な一貫性

解決策の概要

ローカルメッセージテーブルソリューションは、もともとeBayによって提案されました。コアのアイデアは、分散トランザクションを処理のためにローカルトランザクションに分割することです。

解決策は、トランザクションのアクティブなイニシエーターに追加のトランザクションメッセージテーブルを作成することです。トランザクションイニシエーターはビジネスを処理し、ローカルトランザクションでトランザクションメッセージを記録し、トランザクションメッセージテーブルにデータを投票してトランザクションメッセージを送信し、トランザクションのパッシブパーティはメッセージミドルウェアに基づいてトランザクションメッセージテーブルでトランザクションを消費します。

この設計は、「ビジネス処理の成功 +トランザクションメッセージの送信失敗」または「ビジネス処理の失敗 +トランザクションメッセージの送信成功」のトリッキーな状況を回避し、2つのシステムトランザクションのデータの一貫性を確保できます。

処理フロー

分散トランザクションの処理を開始するトランザクションパーティーは、トランザクションアクティブパーティーと呼ばれ、取引アクティブパーティが取引パッシブパーティーと呼ばれる後に処理されたビジネス内の他のトランザクションが呼ばれます。

理解のために、例としてeコマースの注文を使用してソリューションを分析し続けましょう。ここでは、プロセス全体が単純に2つのステップに分割されます。在庫を差し引き、注文の作成です。

在庫サービスと注文サービスは異なるサーバーノード上にあり、在庫サービスはトランザクションのアクティブパーティであり、注文サービスはトランザクションのパッシブパーティです。

トランザクションのアクティブパーティは、分散トランザクションメッセージの発生と処理ステータスを記録するために、追加のトランザクションメッセージテーブルを作成する必要があります。

ビジネス処理フロー全体は次のとおりです。

ステップ1：トランザクションイニシエーターは、ローカルトランザクションを処理します。

トランザクションイニシエーターは、ローカルトランザクションでビジネス更新操作とメッセージテーブル書き込み操作を処理します。上記の例では、在庫サービス段階では、ローカルトランザクションで在庫とメッセージテーブルへの書き込みの控除を完了します（図の1と2）。

ステップ2：トランザクションのアクティブパーティは、トランザクションの受動的な当事者に通知して、メッセージミドルウェアを介したメッセージを保留中のトランザクション通知トランザクションを処理します。

メッセージミドルウェアは、KafkaおよびRocketMQメッセージキューに基づいています。トランザクションイニシエーターはメッセージキューにメッセージを積極的に書き込み、トランザクションコンシューマーはメッセージキュー内のメッセージを消費および処理します。

上記の例では、インベントリサービスがメッセージの中間ウェアへのメッセージ保留中のトランザクションを書き込み、注文サービスはメッセージミドルウェアからメッセージを消費して、新しい注文を完了します（図の3-5）。

ステップ3：トランザクションのパッシブパーティは、メッセージミドルウェアを介してトランザクションが処理されたというメッセージのアクティブパーティに通知されます。

上記の例では、Order Serviceは、Transaction Processedメッセージをメッセージミドルウェアに書き込み、インベントリサービスはミドルウェアからメッセージを消費し、トランザクションメッセージのステータスを完成したものに更新します（図の6-8）。

データの一貫性のために、処理エラーがレトリを必要とする場合、トランザクション送信者に関連するビジネス処理とトランザクションレシーバーがiDempotenceをサポートする必要があります。

一貫性を維持するための特定の障害耐性処理は次のとおりです。

1. ステップ1が失敗すると、トランザクションがロールバックされます。これは、何も起こらないことを意味します。
2. ステップ2と3が処理に失敗した場合、未処理のトランザクションメッセージは引き続きトランザクション送信者に保存されているため、トランザクション送信者は定期的に時限メッセージデータを投票し、再び処理するためにメッセージミドルウェアに送信できます。トランザクションのパッシブパーティは、トランザクションメッセージと再試行を消費します。
3. それがビジネスの失敗である場合、取引のパッシブパーティーは、トランザクションのアクティブパーティーにメッセージを送信してロールバックできます。
4. 複数のトランザクションパッシブパーティがメッセージを消費した場合、トランザクションアクティブパーティは、トランザクションアクティブパーティがトランザクションをロールバックする必要があるときにトランザクションのパッシブパーティに通知する必要があります。

ソリューションの概要

計画の利点は次のとおりです。

• メッセージデータの信頼性は、アプリケーションの設計と開発の観点から実現されます。メッセージデータの信頼性は、メッセージミドルウェアに依存せず、MQミドルウェア特性への依存性を弱めます。
• ソリューションは軽量で実装が簡単です。

欠点は次のとおりです。

• 特定のビジネスシナリオに拘束され、強力な結合があり、公に使用することはできません。
• メッセージデータはビジネスデータと同じであり、ビジネスシステムのリソースを占有しています。
• ビジネスシステムがリレーショナルデータベースを使用する場合、メッセージサービスのパフォーマンスは、リレーショナルデータベースの並行性パフォーマンスによって制限されます。

MQトランザクション：究極の一貫性

計画の紹介

MQに基づく分散トランザクションスキームは、実際にはローカルメッセージテーブルのカプセル化であり、これはローカルメッセージテーブルに基づいています。他の側面のプロトコルは、基本的にローカルメッセージテーブルと一致しています。

処理プロセス

以下は、主にRocketMQ 4.3の後のバージョンに基づいて、MQの分散トランザクションスキームを導入します。

ローカルメッセージテーブルスキームでは、ビジネステーブルデータを送信するトランザクションプロアクティブパーティとメッセージテーブルデータがデータベーストランザクションに基づいていることを確認します。 RocketMQトランザクションメッセージは通常のMQと比較され、2PC提出インターフェイスを提供します。スキームは次のとおりです。

通常の状況：トランザクションはメッセージを送信します

この場合、トランザクションプロアクティブパーティのサービスは正常であり、失敗はありません。メッセージ送信プロセスは次のとおりです。

• 図1：MQサーバー（MQサーバー）に送信すると、半分のメッセージが送信されます。
• 図2：MQサーバーがメッセージを正常に持続させた後、送信者ACKに確認して、メッセージが正常に送信されたことを確認します。
• 図3：送信者は、ローカルトランザクションロジックの実行を開始します。
• 図4：送信者は、ローカルトランザクションの実行結果に基づいて、MQサーバーに二次確認（コミットまたはロールバック）を提出します。
• 図5：MQサーバーがコミットステータスを受信すると、ハーフメッセージが成果物としてマークされ、サブスクライバーが最終的にメッセージを受信します。 MQサーバーがロールバックステータスを受信すると、ハーフメッセージが削除されると、サブスクライバーはメッセージを受け入れません。

例外：トランザクションプロアクティブなメッセージ回復

ネットワークの切断やアプリケーションの再起動などの異常な状況では、図4の4が提出した二次確認タイムアウトはMQサーバーに到達しませんでした。この時点での処理ロジックは次のとおりです。

• 図5：MQサーバーがメッセージへのメッセージの返信を開始します。
• 図6：送信者がメッセージバック検索を受信した後、彼は対応するメッセージのローカルトランザクション実行の最終結果を確認する必要があります。
• 図7：送信者は、検査で得られたローカルトランザクションの最終的なステータスに基づいて、二次確認を再度提出します。
• 図8では、MQサーバーは、コミット/ロールバックに基づいてメッセージを配信または削除します。

RocketMQのトランザクションメッセージプランを導入した後、ローカルメッセージテーブルプランが以前に導入されたため、RocketMQ分散トランザクションを簡単に紹介します。

トランザクションプロアクティブパーティーは、MQ通信に基づいてトランザクションを処理するためにトランザクションパッシブパーティに通知し、トランザクションパッシブパーティはMQに基づいて処理結果を返します。

トランザクションパッシブパーティがメッセージを異常に消費する場合、継続的に再試行する必要があり、ビジネス処理ロジックは等である必要があります。

トランザクションパッシブパーティがビジネス処理に失敗した場合、トランザクションプロアクティブパーティーにMQを通じて通知して、トランザクションロールバックを補償できます。

計画の概要

ローカルメッセージテーブルスキームと比較して、MQトランザクションスキームの利点は次のとおりです。

• メッセージデータは独立して保存され、ビジネスシステムとメッセージシステムの間の結合が減少します。
• スループットは、ローカルメッセージテーブルスキームの使用によるものです。

欠点は次のとおりです。

• メッセージ送信には、2つのネットワークリクエスト（半分のメッセージ +コミット/ロールバックメッセージ）が必要です。
• サービス処理サービスは、メッセージステータスチェックインターフェイスを実装する必要があります。

SAGAトランザクション：究極の一貫性

計画の紹介

サガトランザクションは、プリンストン大学のヘクトとケネスによる1987年の論文から生まれました。

SAGAトランザクションの中心的なアイデアは、SAGAトランザクションコーディネーターによって調整された、長いトランザクションを複数のローカルショートトランザクションに分割することです。正常に終了すると、正常に完了します。ステップが失敗した場合、補償操作は逆の順序で1回呼び出されます。

処理プロセス

SAGA取引の基本契約は次のとおりです。

• 各SAGAトランザクションは、一連のiDEMPOTENTサブトランザクションTIで構成されています。
• 各TIには、TIによって引き起こされる結果をキャンセルするために使用される対応するIDEMPOTENT補償アクションCIがあります。

ご覧のとおり、TCCと比較して、SAGAには「予約」アクションがなく、そのTIはライブラリに直接提出されます。

次の注文プロセスは例としてです。操作全体には、注文の作成、在庫の控除、支払い、および増加ポイントが含まれます。

上の図に示すように、サガには2つの実行命令があります。

• トランザクションの通常の実行が完了します：T1、T2、T3、...、TN、たとえば：在庫（T1）、順序の作成（T2）、支払い（T3）、および順番に順番にトランザクション全体を完了します。
• トランザクションロールバック：T1、T2、...、TJ、CJ、...、C2、C1、ここで、0 <J <n、例：duct inventory（t1）、create order（t2）、pay（t3、payin failed）、pay rollback（c3）、Order Rollback（C2）、Restore Inventory（C1）。

SAGAは2つの回復戦略を定義しています。

前方回復：上記の実行順序に対応すると、成功が必要なシナリオに適しています。障害が発生した場合、retryはこれに似ています：t1、t2、...、tj（failed）、tj（retry）、...、tn、jはエラーが発生したサブトランザクションです。この場合、CIは必要ありません。

後方回復：上記の2番目の実行順序に対応します。ここで、Jはエラーで発生したサブトランザクションです。このアプローチの効果は、以前のすべての成功したサブトランザクションをキャンセルし、佐賀全体の実行結果を取り消すことです。

SAGAトランザクションには2つの異なる実装方法があります。

commandコマンド調整（Order Orchestrator）：中央コーディネーターは、イベントの意思決定とビジネスロジックのソートを中央に処理する責任があります。

セントラルコーディネーター（OSO）は、各サービスとコマンド/返信方法で通信し、各参加者に何をすべきか、いつ何をすべきかを伝える責任を単独で担当します。

例として、eコマースの注文の例を考えてみましょう。

• トランザクションイニシエーターの主なビジネスロジックは、OSOサービスに注文トランザクションを開始するよう要求します
• OSOは在庫サービスから在庫控除を要求し、在庫サービスは処理結果に対応します。
• OSOは注文サービスを要求して注文を作成し、注文サービスが応答して結果を作成します。
• OSOは支払いサービスから支払いを要求し、支払いサービスは処理結果に応答します。
• 主なビジネスロジックは、OSOトランザクションの結果に対する応答を受け取り、処理します。

中央のコーディネーターは、注文トランザクション全体を実行するために必要なプロセスを事前に知る必要があります（たとえば、構成を読み取ることによって）。失敗がある場合は、各参加者にコマンドを送信して以前の操作を取り消すことにより、分散ロールバックを調整する責任があります。

中央コーディネーターに基づいてすべてを調整する場合、コーディネーターはデフォルトでフォワードプロセスを実行するため、ロールバックははるかに簡単になり、ロールバック時に逆プロセスのみが実行されます。

②イベントChoreography0：中央のコーディネーター（リスクの単一のポイントがない）がない場合、各サービスは他のサービスのイベントを生成および観察し、行動をとるべきかどうかを決定します。

オーケストレーション方法では、最初のサービスがトランザクションを実行し、イベントを公開します。このイベントは、ローカルトランザクションを実行し、新しいイベントを公開（または公開しない）1つ以上のサービスで聴きます。

サービスがローカルトランザクションを実行し、イベントを公開しない場合、それは分散トランザクションが終了すること、またはそれが公開するイベントがSAGA参加者によって聞かれないことを意味します。それはトランザクションが終了することを意味します。

例として、eコマースの注文の例を考えてみましょう。

トランザクションイニシエーターの主なビジネスロジックは、注文イベントを公開します。

• 在庫サービスは、開始注文イベントを監視し、在庫を控除し、在庫控除イベントを公開します。
• 注文サービスは、インベントリ控除イベントの耳を傾け、注文を作成し、作成したイベントを公開します。
• ペイメントサービスは、作成されたイベントの注文のリスティング、支払いを行い、有料イベントを公開します。
• 主なビジネスロジックは、注文の有料イベントを監視し、処理します。

イベント/オーケストレーションは、サガパターンを実装するための自然な方法です。簡単で理解しやすく、構築するのにあまり多くのコードを必要としません。これは、トランザクションに2〜4ステップが含まれる場合、非常に適している場合があります。

計画の概要

コマンド調整設計の利点は次のとおりです。

• SAGAコーディネーターがSAGA参加者を呼び出すが、参加者はコーディネーターに電話をかけていないため、サービス間の関係は単純で、サービス間の循環依存関係を回避します。
• プログラムの開発は簡単で、コマンド/返信の実行のみが必要です（実際、返信メッセージもイベントメッセージです）。参加者の複雑さを削減します。
• メンテナンスの簡単な拡張機能、トランザクションの複雑さは、新しいステップを追加するときに直線的なままです。ロールバックは管理しやすく、実装とテストが簡単です。

コマンド調整設計の欠点は次のとおりです。

• 中央のコーディネーターは、簡単に過度に複雑なロジックを簡単に処理し、維持が困難になります。
• コーディネーターの失敗の単一のポイントのリスクがあります。

イベント/オーケストレーション設計の利点は次のとおりです。

• 中央コーディネーターの単一点障害のリスクを避けてください。
• 関与する手順が少ない場合、サービス開発は簡単で実装が簡単です。

イベント/オーケストレーション設計の欠点は次のとおりです。

• サービス間に循環依存のリスクがあります。
• 多くの手順が関係している場合、サービス間の関係は混oticとしており、追跡と測定が困難です。

SAGAモデルには準備段階がないため、トランザクション間に分離を保証できないことを追加する価値があります。

複数のSAGAトランザクションが同じリソースで動作する場合、更新損失やダーティデータの読み取りなどの問題が発生します。現時点では、アプリケーションレベルでのロックやアプリケーションレベルでのリソースの事前凍結など、ビジネスレベルで並行性を制御する必要があります。

5。概要

ソリューションごとにシナリオを使用します

分散トランザクションの理論と一般的なソリューションを導入した後、最終的な目標は実際のプロジェクトに適用されることです。したがって、各ソリューションの一般的な使用シナリオを要約しましょう。

• 2PC/3PC ：データベースに依存すると、強力な一貫性と強力な取引性を提供できますが、比較的高いレイテンシを提供します。これは、従来のモノリシックアプリケーションにより適しています。同じ方法にはクロスストアの操作があり、高い並行性と高性能要件を備えたシナリオには適していません。
• TCC：実行時間を決定するのに適しており、リアルタイムの要件が高く、データの一貫性の要件が高い短いです。たとえば、インターネット金融会社の3つの最もコアサービス：取引、支払い、会計。
• ローカルメッセージテーブル/MQトランザクション：どちらも、参加者が運用上のアイデルをサポートするトランザクションに適しており、一貫性の要件が高い。このビジネスは、データの矛盾を手動検査サイクルに容認することができます。この取引には、参加者と参加リンクが少なくなり、ビジネスを保証するための和解/チェックシステムがあります。
• SAGAトランザクション： SAGA取引は隔離を保証することはできないため、ビジネスレベルでの同時性を制御する必要があります。これは、リソースの少ないビジネスシナリオトランザクションの同時運用に適しています。

SAGAの勤​​務前のアクションの欠如と比較して、補償措置を実装することがより面倒になります。たとえば、サービスはテキストメッセージを送信することであり、メッセージのキャンセルを示すために報酬アクションを再度送信する必要があります。これはユーザーエクスペリエンスが低いです。 SAGAトランザクションは、補償アクションが簡単に処理できるシナリオにより適しています。

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

この記事で導入された原則は偏っています。業界にはすでに多くのオープンソースまたは有料のソリューションがあります。スペースの制限のため、私はそれを二度と紹介しません。

実際のアプリケーションで理論を使用する場合、多くの人々は「手にハンマーを持っていると、すべてが爪のように見えます」という間違いを犯しやすいです。計画を設計する際に考慮すべき問題のシナリオが多すぎる、さまざまな再試行、およびさまざまな補償メカニズムがシステムに導入され、システムが複雑すぎて実装が遠く離れています。

• 世界でコンピューターの問題を解決する最も簡単な方法：「Just Avass」はそれを解決する必要はありません！

- Alibabaミドルウェアの専門家であるShen Xun

いくつかの問題は重要と思われますが、実際には、それらを合理的に設計するか、壊すことでそれらを避けることができます。

分散トランザクションシステムを設計しても、すべての例外を考慮する必要はなく、さまざまなロールバックおよび補償メカニズムを過剰に設計する必要はありません。

問題自体を解決するのに時間を費やさなければならない場合、それは非効率的であるだけでなく、無駄でもあります。

システムがロールバックプロセスを実装したい場合、システムの複雑さが大幅に改善され、バグが傾向があります。バグの確率は、トランザクションロールバックの確率よりもはるかに大きくなると推定されています。

システムを設計するとき、このような問題を解決するために非常に多く費やす価値があるかどうかを測定する必要があります。非常に少ない確率でこの問題が発生したときに、手動で解決できるかどうかを検討できます。これは、困難な問題を解決するときに誰もがもっと考える必要があるものでもあります。

参考文献：

• テクノロジートーク - - トランザクション
• MySQLでのトランザクションの実装
• 分散一貫性アルゴリズム2PCおよび3PC
• 分散オープンメッセージシステムの原則と実践（RocketMQ）
• RocketMQトランザクションメッセージの紹介
• SAGA分散トランザクションソリューションとプラクティス - jiang ning
• 分散トランザクションSAGAモード
• 金貨充電からの分散トランザクションについて考えています

著者に関しては、サーバー側の開発に従事するChen Caihua（Caison）は、システム設計、最適化と再構築、およびオンライン問題調査に優れています。彼の主な開発言語は、Java、Wechat ID：Hua1881375です。

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