分散トランザクションソリューションの概要とSeataの詳細説明

導入

ビジネス量が増加し続けると、モノリシックアーキテクチャは徐々に膨大なトラフィックに耐えられなくなります。このとき、サービスを分割し、データベースとテーブルを別々のライブラリとテーブルに分割する必要があります。発注システムを例にとると、発注センター、ユーザーセンター、在庫センターなどがあります。これによって生じる問題は、業務が互いに分離していることです。各企業は独自のデータベースを維持しており、データ交換は RPC 呼び出しを通じてのみ行うことができます。

ユーザーが再度注文を行う場合、注文ライブラリ、在庫ライブラリ、ユーザーライブラリアカウントに対して同時に操作を実行する必要があります。ただし、現時点ではローカルデータの一貫性のみを保証でき、他のサービスを呼び出す操作が成功するかどうかは保証できません。したがって、注文プロセス全体のデータの一貫性を確保するには、分散トランザクションが必要になります。

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

分散トランザクションを実装するためのソリューションとしては、XA プロトコルに基づく 2PC や 3PC、ビジネス層に基づく TCC、メッセージキュー + メッセージテーブルを適用して実装される最終的な一貫性ソリューションなど、さまざまなものがあります。

XA プロトコルに基づいて実装された分散トランザクションは、トランザクションマネージャーとローカルリソースマネージャーの 2 つの部分に分かれています。ローカルリソースマネージャーは、Oracle、MYSQL などのデータベースによって実装されることが多く、これらのデータベースは XA インターフェイスを実装しており、トランザクションマネージャーはグローバルスケジューラーとして機能します。

2 フェーズコミット (2PC) はビジネスにほとんど影響を与えません。その最大の利点は、ユーザーにとって透明性があることです。ユーザーは、ローカルトランザクションと同様に XA プロトコルに基づく分散トランザクションを使用できるため、トランザクションの ACID 特性を厳密に保証できます。

2PC の欠点も明らかです。これは、強力な一貫性を備えた同期ブロッキングプロトコルです。トランザクションの実行中は、必要なすべてのリソースをロックする必要があります。これは一般に、固定トランザクションと呼ばれます。したがって、一定の実行時間を持つ短いトランザクションに適しており、全体的なパフォーマンスは比較的劣ります。

トランザクションコーディネーターがクラッシュしたり、ネットワークジッターが発生すると、参加者はリソースをロックした状態のままになったり、一部の参加者のみが正常に送信したりして、データの不整合が発生します。したがって、高い同時実行パフォーマンスが最も重要となるシナリオでは、XA プロトコルに基づく分散トランザクションは最適な選択ではありません。

3 フェーズコミット (3PC) は、2 フェーズコミット (2PC) の改良版です。これは、2 フェーズコミットプロトコルのブロッキング問題を解決するために使用されます。コーディネータがクラッシュすると、参加者は最終的な選択を行うことができず、ブロックされたままになり、リソースがロックされます。

2PC では、コーディネータのみにタイムアウトメカニズムがありますが、3PC では、コーディネータと参加者の両方にタイムアウトメカニズムが導入されています。コーディネーターが失敗した場合、参加者は永久にブロックされることはありません。さらに、最終送信フェーズの前に各参加ノードのステータスが一貫していることを確認するために、第 1 フェーズと第 2 フェーズの間に準備フェーズが挿入されます (以下を参照)。

3PC は、コーディネータの障害後に参加者がブロックされる問題を解決するためにタイムアウトメカニズムを使用しますが、余分なネットワーク通信が追加され、パフォーマンスが低下するため、推奨されません。

いわゆる TCC プログラミングモードも、2 フェーズコミットのバリエーションです。違いは、TCC がビジネスレイヤーでコードを記述して 2 フェーズコミットを実装することです。 TCC はそれぞれ Try、Confirm、Cancel の略です。一つの業務運営は、これら3つの方法に対応している必要があります。

次の単一在庫控除を例に挙げます。試行段階では在庫を取得し、確認段階では実際に在庫を減らします。在庫の減額が失敗した場合、キャンセルステージがロールバックされ、在庫が解放されます。

TCC では、各メソッドがトランザクションを直接コミットするため、リソースブロッキングの問題はありません。例外が発生すると、Cancel を使用してロールバックし、補正します。これはしばしば補償取引と呼ばれます。

元々は 1 つの方法でしたが、現在は 3 つの方法のサポートが必要です。 TCC はビジネスに非常に侵襲的であり、このモデルはうまく再利用できないため、開発量の急増につながることがわかります。ネットワークの変動やその他の要因も考慮する必要があります。リクエストが確実に配信されるように再試行メカニズムが用意されているため、インターフェースのべき等性を考慮する必要があります。

メッセージトランザクション (最終的な一貫性)

メッセージトランザクションは、実際にはメッセージミドルウェアに基づく 2 フェーズコミットであり、ローカルトランザクションとメッセージ送信を同じトランザクションに配置して、ローカル操作とメッセージ送信が同時に成功することを保証します。

発注時に在庫を差し引く原理図:

注文システムは在庫減額の準備をするために MQ にメッセージを送信します。 MQ はメッセージを保存し、成功した ACK を返します。
準備されたメッセージの正常な ACK を受信すると、注文システムはローカル注文操作を実行します。メッセージの送信が成功したにもかかわらずローカルトランザクションが失敗することを防ぐために、注文システムは MQ コールバックインターフェイスを実装し、ローカルトランザクションが正常に実行されたかどうかを継続的にチェックします。失敗した場合、準備されたメッセージはロールバックされます。成功した場合、メッセージは最終的にコミットされます。
在庫システムは在庫減額メッセージを消費し、ローカルトランザクションを実行します。控除が失敗した場合、メッセージは再送信されます。再試行回数を超えると、ローカルテーブルは失敗したメッセージを保持し、補正するためにスケジュールされたタスクを開始します。

メッセージミドルウェアに基づく 2 フェーズコミットソリューションは、通常、同時実行性の高いシナリオで使用され、パフォーマンスが大幅に向上する代わりに、強力なデータ一貫性が犠牲になります。ただし、この方法を実装するにはコストと複雑さが比較的高く、実際のビジネス状況によって異なります。

RocketMQ に基づいて結果整合性を実現する方法の詳細については、注文システムのデータ整合性ソリューションと RocketMQ トランザクションメッセージの詳細な説明を参照してください。

分散トランザクションシート

Seata は、2 フェーズコミットから進化した分散トランザクションソリューションでもあり、AT、TCC、SAGA、XA などのトランザクションモードを提供します。

XA モード: 強力な一貫性を備えた段階的トランザクションモード。一定の可用性は犠牲になりますが、ビジネスへの介入はありません。
TCCモード: ビジネスへの介入を伴う、最終的に一貫性のある段階的トランザクションモード
AT モード: ビジネスへの介入のない、最終的に一貫性のある段階的なトランザクションモード。Seata のデフォルトモードでもあります。
SAGA モード: ビジネスへの侵入を伴う長いトランザクションモード

Seata トランザクション管理には、3 つの重要な役割があります。

TC (トランザクションコーディネーター) - トランザクションコーディネーター: グローバルトランザクションとブランチトランザクションのステータスを維持し、グローバルトランザクションのコミットまたはロールバックを調整します。
TM (トランザクションマネージャー) - トランザクションマネージャー: グローバルトランザクションのスコープを定義し、グローバルトランザクションを開始し、グローバルトランザクションをコミットまたはロールバックします。
RM (リソースマネージャー) - リソースマネージャー: ブランチトランザクション処理のリソースを管理し、TC と通信してブランチトランザクションを登録し、ブランチトランザクションのステータスを報告し、ブランチトランザクションをコミットまたはロールバックします。

シータ実施原則

（１）XAモード

Seata の XA モデルは若干調整されていますが、基本的には同じです。

RMフェーズIの作業:

TCに支店取引を登録する
ブランチビジネスSQLを実行するが送信しない
実行状況をTCに報告する

TC フェーズ II 作業:

TC は各ブランチトランザクションの実行ステータスを検出します。すべてが成功した場合は、すべての RM にトランザクションをコミットするように通知します。失敗した場合は、すべてのRMにトランザクションをロールバックするように通知します。

RMフェーズII作業:

トランザクションをコミットまたはロールバックするためのTC指示を受信する

XA モード

【XAモードの実装】

シータのスターターはXAモードの自動組み立てを完了しました。実装は非常に簡単です。手順は次のとおりです。

1. application.yml ファイルを変更し、XA モードを有効にします。

 seata: data-source-proxy-mode: XA # 开启数据源代理的XA模式

2. グローバルトランザクションを開始するエントリメソッドに @GlobalTransactional アノテーションを追加します。

 @GlobalTransactional public Long create(Order order) { // 创建订单orderMapper.insert(order); // 扣余额...略// 扣减库存...略return order.getId(); }

（２）ATモード

AT モードも段階的にコミットされるトランザクションモデルですが、XA モデルのリソースロック期間が長いという欠点を補っています。

フェーズ 1 RM の作業:

支店取引登録
元に戻すログ（データスナップショット）を記録する
ビジネスSQLを実行して送信する
取引ステータスの報告

ステージ 2 提出時の RM の作業:

元に戻すログを削除する

フェーズ 2 ロールバック中の RM の作業:

元に戻すログに基づいて更新前のデータを復元する

ATモード

実行フローは以下のとおりです。

（３）TCCモード

TCC モードは AT モードと非常によく似ています。各ステージは独立したトランザクションです。違いは、TCC が手動コーディングを通じてデータ復旧を実現することです。次の 3 つの方法を実装する必要があります。

試してください: リソースの検出と予約。
確認：資源運用事業を完了する。 Try が成功し、Confirm が成功する必要があります。
Cancel: 予約されたリソースを解放します。これは、try の逆の操作として理解できます。

TCC 動作モデル図:

TCC モード

【TCC空ロールバックと営業停止】

ブランチトランザクションの試行フェーズがブロックされると、グローバルトランザクションがタイムアウトし、2 番目のフェーズでキャンセル操作がトリガーされる可能性があります。 try 操作が実行される前に cancel 操作が実行されます。この場合、キャンセル操作はロールバックできず、空のロールバックを意味します。

空ロールバックされた業務に対して、引き続きtry laterを実行すると、確定もキャンセルもできなくなるため、業務停止となります。ハングを回避するために、空のロールバック後の try 操作を防止する必要があります。