背景

分散トランザクションは、エンタープライズ統合における技術的な難しさであり、あらゆる分散システム アーキテクチャに関係しています。特にマイクロサービス アーキテクチャでは、これらはほぼ避けられません。

酸

データベース トランザクションを正しく実行するための 4 つの基本要素を指します。

1. 原子性
2. 一貫性
3. 分離
4. 耐久性

キャップ

CAP 原則 (CAP 定理とも呼ばれる) は、分散システムにおける一貫性、可用性、およびパーティション耐性を指します。 CAP 原則は、これら 3 つの要素のうち最大 2 つを同時に達成できることを意味します。これら3つすべてを達成することは不可能です。

• 一貫性: 分散システム内のすべてのデータ コピーが同時に同じ値を持つかどうか。
• 可用性: クラスター内の一部のノードに障害が発生した後も、クラスター全体がクライアントの読み取りおよび書き込み要求に応答できるかどうか。
• パーティション耐性: 実際には、パーティションは通信の時間制限に相当します。システムが時間制限内にデータの一貫性を達成できない場合は、パーティションが発生しており、現在の操作に対して C と A のどちらかを選択する必要があることを意味します。

ベース理論

BASE 理論は、CAP における一貫性と可用性のトレードオフの結果です。この理論の核となる考え方は、強い一貫性は実現できないが、各アプリケーションは適切な方法を採用して、独自のビジネス特性に基づいてシステムが最終的な一貫性を実現できるようにするというものです。

• 基本的に利用可能
• ソフトステート
• 最終的に一貫性がある

解決

01 2フェーズコミット（2PC）

2 フェーズ コミット (2PC) は、分散トランザクションの中で最も強力なトランザクション タイプの 1 つです。 2 フェーズ コミットは 2 フェーズ コミットです。最初のフェーズでは、各トランザクション データ ソースの準備ができているかどうかを問い合わせ、2 番目のフェーズでは実際にデータをトランザクション データ ソースに送信します。

トランザクションが ACID を満たすことができるようにするために、コーディネーターを導入する必要があります。その他のノードは参加者と呼ばれます。コーディネーターは、参加者の行動をスケジュールし、最終的に参加者がトランザクションをコミットするかどうかを決定する責任を負います。処理フローは以下のとおりです。

フェーズ1

a) コーディネーターはトランザクションの内容をすべての参加者に送信し、トランザクションを送信できるかどうかを尋ね、応答を待ちます。

b) 各参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。

c) 参加者が正常に実行した場合は、コーディネーターにフィードバックします: はい。それ以外の場合は、フィードバックを送信します: いいえ。

フェーズ2

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

ケース1:参加者全員が「はい」と答えると、トランザクションはコミットされます

a) コーディネーターは、トランザクションを送信するための正式なリクエスト (コミット リクエスト) をすべての参加者に送信します。

b) 参加者はコミット要求を実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は完了を示すためにコーディネータに ack (確認応答) メッセージを送信します。

d) コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションがコミットされます。

ケース2:参加者の1人が「いいえ」と応答すると、トランザクションはロールバックされます

a) コーディネーターはすべての参加者にロールバック要求を送信します。

b) 参加者はフェーズ 1 の元に戻す情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は、コーディネータに ack 完了メッセージをフィードバックします。

d) コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションは完了します。

質問

1) パフォーマンスの問題: トランザクション送信フェーズ中、すべての参加者は同期ブロック状態になり、システム リソースを占有し、パフォーマンスのボトルネックが発生しやすくなります。

2) 信頼性の問題:コーディネーターに単一障害点がある場合、またはコーディネーターに障害が発生した場合、プロバイダーはロックされたままになります。

3) データの一貫性の問題:フェーズ 2 でコーディネーターと参加者の両方に障害が発生すると、データの不整合が発生する可能性があります。

利点:可能な限り強力なデータ一貫性が保証され、強力なデータ一貫性が求められる重要な領域に適しています。 (実際、強い一貫性は 100% 保証されません)。

デメリット:実装が複雑で、可用性が犠牲になり、パフォーマンスに大きな影響を与え、高同時実行性と高パフォーマンスのシナリオには適していません。

02 3相コミット（3PC）

3 フェーズ コミットは、2 フェーズ コミットの改良版です。 3PC が解決する必要がある最も重要な問題は、コーディネータと参加者の両方が同時に失敗する問題であるため、3PC は 2PC の準備フェーズを再び 2 つに分割し、3 フェーズ コミットを形成します。処理フローは以下のとおりです。

フェーズ1

a) コーディネーターは、トランザクションの内容を含む canCommit リクエストをすべての参加者に送信し、トランザクションをコミットできるかどうかを尋ね、すべての参加者からの応答を待ちます。

b) canCommit リクエストを受信した後、参加者がトランザクション操作を実行できると判断した場合は yes をフィードバックして準備状態に入り、そうでない場合は no をフィードバックします。

フェーズ2

コーディネーターには、参加者の反応に応じて 2 つの可能性があります。

ケース1:参加者全員が「はい」と応答し、コーディネーターがトランザクションを事前実行する

a) コーディネーターはすべての参加者に preCommit リクエストを送信し、準備フェーズに入ります。

b) preCommit 要求を受信した後、参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。

c) 各参加者は、コーディネータに ack 応答または no 応答をフィードバックし、最終指示を待ちます。

ケース 2:参加者の 1 人が「いいえ」と応答するか、コーディネーターが待機タイムアウト後にすべてのプロバイダーからフィードバックを受信できない場合、トランザクションは終了します。

a) コーディネーターはすべての参加者に中止要求を送信します。

b) 参加者は、コーディネータから中止要求を受信したか、コーディネータの要求を待機中にタイムアウトが発生したかに関係なく、トランザクションを中止します。

フェーズ3

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

ケース1:すべての参加者がackで応答し、トランザクションがコミットされる

a) コーディネーターが作業状態の場合、すべての参加者に do Commit 要求を送信します。

b) do Commit 要求を受信した後、参加者はトランザクションのコミットを正式に実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は、コーディネータに ack 完了メッセージをフィードバックします。

d) コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションがコミットされます。

ケース 2:参加者の 1 人が「いいえ」と応答するか、調整グループが待機タイムアウト後にすべてのプロバイダーからフィードバックを受信できない場合、トランザクションはロールバックされます。

a) コーディネーターが作業状態にある場合、すべての参加者にロールバック要求を送信します。

b) 参加者はフェーズ 1 の元に戻す情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は調整グループに ack 完了メッセージをフィードバックします。

d) コーディネーション グループがすべての参加者から ack メッセージを受信すると、トランザクションのロールバックが完了します。

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

デメリット:データの不整合の問題が依然として存在します。参加者が preCommit 要求を受信し、do commit 指示を待機しているときに、コーディネータがトランザクションの中断を要求し、コーディネータが参加者と正常に通信できない場合、参加者はトランザクションの送信を継続し、データの不整合が発生します。

03 報酬業務（TCC）

TCC は、次の補正メカニズムを使用するサービス指向の 2 段階プログラミング モデルです。

状態：

確認と補償ロジックを実装する必要がある

べき等性をサポートする必要がある

処理フロー:

a) 試行フェーズは主にビジネス システムをテストし、リソースを予約するために使用されます。

このフェーズでは主に次の作業が完了します。

すべてのビジネスチェック（一貫性）が完了しました。

必要なビジネスリソースを確保します（準分離）。

操作の実行を試みます。

b) 確認段階では、主に確認してビジネス システムに送信します。

試行フェーズが正常に実行され、確認フェーズが開始されると、確認フェーズはデフォルトでは失敗しません。つまり、Try が成功する限り、Confirm も成功します。

c) キャンセルステージは、主にエラーが発生してロールバックが必要になったときに実行された業務操作をキャンセルし、予約されたリソースを解放するために使用されます。

アドバンテージ：

パフォーマンスの向上: 特定の業務で制御されるリソース ロックの粒度が小さくなり、リソース全体がロックされなくなります。

最終的なデータ一貫性: Confirm と Cancel のべき等性に基づいて、トランザクションは最終的に確認またはキャンセルされることが保証され、データの一貫性が確保されます。

信頼性: XA プロトコルのコーディネータの単一点障害問題が解決されます。ビジネスアクティビティ全体は、主要なビジネスパーティによって開始および制御され、ビジネスアクティビティマネージャもマルチポイントになり、クラスターを導入します。

デメリット: TCC の Try、Confirm、Cancel 操作機能は特定の業務に応じて実装する必要があり、業務の結合度が高くなり、開発コストが増加します。

04 ローカルメッセージテーブル（メッセージキュー）

中心となる考え方は、分散トランザクションをローカル トランザクションに分割して処理することです。

解決策は、コンシューマー用に追加のトランザクション メッセージ テーブルを作成することです。コンシューマーはビジネスを処理し、ローカル トランザクションにトランザクション メッセージを記録し、トランザクション メッセージ テーブル内のデータをポーリングしてトランザクション メッセージを送信し、プロバイダーはメッセージ ミドルウェアに基づいてトランザクション メッセージ テーブル内のトランザクションを消費します。

状態：

サービス コンシューマーは、メッセージ ステータスを記録するためにメッセージ テーブルを作成する必要があります。

サービスの消費者とプロバイダーは冪等性をサポートする必要があります。

補正ロジックが必要です。

各ノードでタイミング スレッドが開始され、処理されていないメッセージや送信に失敗したメッセージをチェックし、メッセージを再送信します。これが再試行メカニズムとべき等性メカニズムです。

処理フロー:

1. サービス コンシューマーはビジネス データとメッセージを一緒に送信し、トランザクションを開始します。

2. メッセージは MQ を介してサービスプロバイダーに送信され、サービスコンシューマーは処理結果を待機します。

3. サービス プロバイダーはメッセージを受信し、ビジネス ロジックを完了して、処理されたメッセージをコンシューマーに通知します。

フォールト トレランス プロセスは次のとおりです。

ステップ 1 が失敗すると、トランザクションはロールバックされ、何も起こらないのと同じになります。

手順 2 と 3 が失敗した場合、メッセージはコンシューマー テーブルに保存されるため、再試行のために MQ に再送信できます。

ステップ 3 でエラーが発生し、それがビジネス障害である場合、サービス プロバイダーはトランザクションが失敗したことをコンシューマーに通知するメッセージを送信し、コンシューマーはロールバック トランザクションを開始してロールバック ロジックを実行します。

利点:アプリケーションの設計と開発の観点から、メッセージ データの信頼性が実現されます。メッセージ データの信頼性はメッセージ ミドルウェアに依存しないため、MQ ミドルウェアの特性への依存が弱まります。

デメリット:特定のビジネス シナリオに限定され、結合度が高く、一般に公開されていません。メッセージ データとビジネス データが同じデータベースに保存され、ビジネス システムのリソースを占有します。ビジネス システムでリレーショナル データベースを使用する場合、メッセージ サービスのパフォーマンスはリレーショナル データベースの同時実行パフォーマンスによって制限されます。

MQ トランザクション メッセージ (結果整合性)

MQ は、2 フェーズ コミットと同様の方法でトランザクション メッセージをサポートします。

MQ ベースの分散トランザクション ソリューションは、実際にはローカル メッセージ テーブルをカプセル化したものです。ローカル メッセージ テーブルは MQ に基づいており、他の側面のプロトコルは基本的にローカル メッセージ テーブルと一致しています。

状態：

a) 補償ロジックが必要

b) ビジネス処理ロジックはべき等性を持つ必要がある

処理フロー:

c) コンシューマーは MQ に半分のメッセージを送信します。

d) MQ サーバーはメッセージを保持した後、メッセージが正常に送信されたことを確認するために送信者に ack を送信します。

e) コンシューマーはトランザクションロジックの実行を開始します。

f) コンシューマーは、ローカルトランザクションの実行結果に基づいて、2 番目の確認またはロールバックを MQ サーバーに送信します。

g) MQ サーバーはコミット ステータスを受信すると、半分のメッセージを配信可能としてマークします。

h) サービスプロバイダーはメッセージを受信し、ローカルビジネスロジックを実行します。処理結果を返します。

アドバンテージ：

メッセージ データは独立して保存されるため、ビジネス システムとメッセージ システム間の結合が軽減されます。

スループットはローカル メッセージ テーブル ソリューションよりも優れています。

欠点:

メッセージを送信するには、2 つのネットワーク要求 (メッセージの半分 + コミット/ロールバック) が必要です。

メッセージ コールバック インターフェイスを実装する必要があります。

05 Sagas トランザクション モデル (結果整合性)

Saga モードは、分散非同期トランザクション、最終的に一貫性のあるトランザクション、および柔軟なトランザクションです。 saga トランザクションを実装するには 2 つの方法があります。最も一般的な 2 つの方法は次のとおりです。

1. イベント/コログラフィ: 中央コーディネーターが存在しない (単一ポイントのリスクがない) 場合、各サービスは他のサービスからのイベントを生成してリッスンし、アクションを実行するかどうかを決定します。

実装では、まずトランザクションを実行し、次にイベントを公開します。イベントは 1 つ以上のサービスによってリッスンされ、ローカル トランザクションが実行され、新しいイベントが発行されます (または発行されません)。最後のサービスがローカル トランザクションを実行し、イベントを何も発行しない場合は、分散トランザクションが終了したか、発行したイベントがどの Saga 参加者にも聞こえず、トランザクションが終了したことを意味します。

処理フロー:

注文サービスは新しい注文を保存し、状態を保留に設定し、ORDER_CREATED_EVENT というイベントを公開します。

支払いサービスは ORDER_CREATED_EVENT をリッスンし、イベント BILLED_ORDER_EVENT を公開します。

在庫サービスは、BILLED_ORDER_EVENT をリッスンし、在庫を更新し、ORDER_PREPARED_EVENT を公開します。

配送サービスは ORDER_PREPARED_EVENT をリッスンし、商品を配送します。最後に、ORDER_DELIVERED_EVENT を公開します。

最後に、注文サービスは ORDER_DELIVERED_EVENT をリッスンし、注文のステータスを「完了」に設定します。

トランザクションの途中で在庫サービスが失敗したとします。ロールバックするには:

在庫サービスはPRODUCT_OUT_OF_STOCK_EVENTを生成します

注文サービスと支払いサービスは、上記の在庫サービスのこのイベントをリッスンします。

①決済サービスがお客様に返金いたします。

②注文サービスは注文ステータスを失敗に設定します。

利点:イベント/振り付けは、Saga パターンを実装する自然な方法です。シンプルで理解しやすく、構築に多くの労力を必要とせず、すべての参加者は互いに直接結合されていないため疎結合です。取引に 2 ～ 4 つのステップが含まれる場合は、これが適している可能性があります。

2. コマンド/調整オーケストレーター: 中央コーディネーターは、集中的なイベント意思決定とビジネス ロジックのシーケンス処理を担当します。

saga コーディネーターは、コマンド/応答方式で各サービスと通信し、実行する必要があるアクションを指示します。

注文サービスは保留状態を保存し、注文 Saga コーディネーター (OSO) に注文トランザクションを開始するように要求します。

OSO は支払い実行コマンドを支払いサービスに送信し、支払いサービスは支払い実行メッセージで応答します。

OSO は在庫サービスに注文準備コマンドを送信し、在庫サービスは OrderPrepared メッセージで応答します。

OSO は貨物サービスに注文配送コマンドを送信し、貨物サービスは注文配送済みメッセージで応答します。

OSO Order Saga コーディネータは、「注文の作成」トランザクションを実行するために必要なプロセス (BPM ビジネス プロセス XML 構成を読み取ることによって取得) を事前に知っておく必要があります。何かが失敗した場合、各参加者にコマンドを送信して以前の操作を元に戻すことにより、分散ロールバックを調整する役割も担います。すべてを調整する中央コーディネーターがある場合、コーディネーターがデフォルトで順方向プロセスを実行し、ロールバックするときに逆方向プロセスを実行するだけなので、ロールバックははるかに簡単になります。

アドバンテージ：

saga コーディネーターは saga 参加者を呼び出しますが、参加者はコーディネーターを呼び出さないため、サービス間の循環依存関係を回避します。

分散トランザクションのオーケストレーションを集中化します。

コマンド/応答を実行するだけでよいため (実際、応答メッセージもイベント メッセージの一種です)、参加者の複雑さが軽減されます。

新しいステップが追加されても、トランザクションの複雑さは直線的に維持され、ロールバックの管理が容易になります。

最初のトランザクションが完了する前に 2 番目のトランザクションのターゲット オブジェクトを変更する場合は、最初のトランザクションが完了するまでコーディネータ上で簡単に中断できます。