実戦！ Ali アーティファクト Seata は分散トランザクションを解決するために TCC モードを実装しています。素晴らしいですね!

この記事はWeChat公式アカウント「Mayuan Technology Column」から転載したもので、著者はChenです。この記事を転載する場合は、CodeApeテクノロジーコラム公式アカウントまでご連絡ください。

本日の記事では、Seata が TCC トランザクションモードを実装する方法を紹介します。記事ディレクトリは以下の通りです。

TCC モードとは何ですか?

TCC (Try Confirm Cancel) ソリューションは、アプリケーションレベルの侵入サービスの 2 段階の送信です。これは現在最も人気のある柔軟な取引ソリューションです。その中心的な考え方は、各操作に対して、対応する確認および補償（キャンセル）操作を登録する必要があるということです。

TCC は次の 2 つのフェーズに分かれています。

第一段階：トライ（試行）、主に業務システムのテストとリソースの予約（ロックとロックリソース）
フェーズ 2: このフェーズでは、フェーズ 1 の結果に基づいて、確認するかキャンセルするかを決定します。

確認: 実際の業務を実行します（業務を実行し、ロックを解除します）

キャンセル: 予約したリソースをキャンセルします (問題がある場合はロックを解除します)

TCC

理解を容易にするために、次のソリューションでは、電子商取引の注文を例にして分析します。ここでは、プロセス全体が在庫の減算と注文の作成という 2 つのステップに分割されます。在庫サービスと注文サービスは異なるサーバーノード上にあります。

商品在庫が100個、購入数量が2個であるとします。ここで、在庫の確認と更新を行っている最中に、ユーザーの購入数量の在庫が凍結され、同時に注文が作成され、注文ステータスが確認待ちとなります。

①トライステージ

TCC メカニズムの Try は、単なる予備操作です。これとその後の確認を組み合わせることで、完全なビジネスロジックを形成できます。このステージでは主に次の作業が完了します。

すべてのビジネスチェック（一貫性）が完了しました。
必要なビジネスリソースを確保します（準分離）。
操作の実行を試みます。

トライステージ

②確認・キャンセル段階

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

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

確認: 試行フェーズのすべてのサービスが正常に実行されると、確認ビジネスロジック操作が実行されます。事業内容は次の図の通りです。

試す->確認

ここで使用するリソースは、Try フェーズで予約されたビジネスリソースである必要があります。 TCC トランザクションメカニズムでは、Try フェーズでリソースを正常に予約できれば、Confirm を完全に正しく送信できると考えられます。

確認段階は、試行段階の補足として見ることもできます。 Try+Confirm を組み合わせることで、完全なビジネスロジックが形成されます。

キャンセル: 試行フェーズでサービスの実行に失敗した場合、キャンセルフェーズが開始されます。事業内容は以下のとおりです。

試す-キャンセル

「キャンセル」は実行をキャンセルし、Try ステージで予約されたビジネスリソースを解放します。上記の例では、キャンセル操作により凍結された在庫が解放され、注文ステータスがキャンセルに更新されます。

上記が TCC モードの全体的な概念です。この部分は、Chen の以前の記事でも詳しく紹介されています: 7 つの分散トランザクションソリューションを比較すると、私は依然として Alibaba のオープンソース Seata を好みます。これは本当に優れています。（原理＋実践）

TCC モードの 3 つのタイプは何ですか?

TCC モデルは業界で実際の生産に展開されており、次の 3 つのタイプがまとめられています。実は、公式の定義にはそのような記述はなく、企業の生産現場における実際のニーズから導き出された 3 つのソリューションです。

1. ユニバーサルTCCソリューション

一般的な TCC ソリューションは、TCC トランザクションモデルの最も古典的な実装です。最初のセクションで説明したように、すべてのスレーブビジネスはマスタービジネスの意思決定に参加します。

ユニバーサル TCC

適用可能なシナリオ:

スレーブビジネスサービスは同期的に呼び出されるため、その結果はマスタービジネスサービスの決定に影響します。したがって、一般的な TCC 分散トランザクションソリューションは、電子商取引システムの 3 つのコアサービスである注文サービス、アカウントサービス、在庫サービスなど、実行時間が一定かつ短いビジネスに適しています。

これら 3 つのサービスは、同時に成功するか、同時に失敗します。

在庫サービスとアカウントサービスを呼び出す第 2 フェーズが完了すると、分散トランザクション全体が完了します。

2. 非同期保証TCCソリューション

非同期保証 TCC ソリューションの直接スレーブビジネスサービスは信頼性の高いメッセージサービスですが、実際のスレーブビジネスサービスはメッセージサービスを通じて分離され、メッセージサービスのコンシューマーとして非同期に実行されます。

非同期保証

信頼性の高いメッセージサービスでは、Try、Confirm、Cancel の 3 つのインターフェイスを提供する必要があります。 Try インターフェースは事前送信に使用され、メッセージデータを永続的に保存する役割のみを果たします。 Confirm インターフェースが送信を確認し、その後に実際のメッセージ配信が開始されます。キャンセルインターフェイスは送信をキャンセルし、メッセージデータを削除します。

メッセージサービスのメッセージデータは独立して保存および拡張されるため、ビジネスサービスとメッセージシステム間の結合が軽減されます。信頼性の高いメッセージサービスの前提の下で、分散トランザクションの最終的な一貫性が実現されます。

このソリューションではメッセージサービスの保守コストが増加しますが、メッセージサービスがビジネスサービスの代わりに TCC インターフェイスを実装するため、ビジネスサービスを変更する必要がなく、アクセスコストは非常に低くなります。

適用可能なシナリオ:

ビジネスサービスからのメッセージの消費は非同期プロセスであるため、実行時間は不確実であり、一貫性のない時間ウィンドウが増加する可能性があります。したがって、非同期的に保証される TCC 分散トランザクションソリューションは、最終的な一貫性の時間に対する敏感性がそれほど高くない一部のパッシブビジネスにのみ適しています (スレーブビジネスサービスの処理結果はメインビジネスサービスの決定に影響を与えず、メインビジネスサービスの決定結果を受動的に受信するだけです)。例えば、会員登録サービスやメール送信サービスなど。

3. 補償TCCソリューション

補償型 TCC ソリューションの構造は一般的な TCC ソリューションの構造と似ており、そのスレーブビジネスサービスもメインビジネスサービスのアクティビティの意思決定に参加する必要があります。ただし、前者はビジネスサービスから Do と Compensate の 2 つのインターフェイスのみを提供する必要があるのに対し、後者は 3 つのインターフェイスを提供する必要があるという違いがあります。

Do インターフェースは実際の完全なビジネスロジックを直接実行し、ビジネス処理を完了し、ビジネス実行結果を外部から表示できます。補償操作は、ビジネス補償、つまり、プラスのビジネス操作のビジネス結果を相殺または部分的に相殺するために使用されます。補償操作はべき等性を満たす必要があります。

一般的なソリューションと比較して、補償ソリューションでは、ビジネスサービスから元のビジネスロジックを変更する必要がありません。追加の補償ロールバックロジックを追加するだけで済み、ビジネス変革の量は比較的少なくなります。ただし、ビジネスではビジネスロジック全体が 1 つのステージで実行され、効果的なトランザクション分離を実現できないことに注意してください。ロールバックが必要な場合、補正が失敗する可能性があり、手動介入などの追加の例外処理メカニズムが必要になります。

適用可能なシナリオ:

ロールバック補償が失敗する可能性があるため、補償 TCC 分散トランザクションソリューションは、同時競合が少ない、または外部とのやり取りが必要な一部のビジネスにのみ適用できます。これら外部業務は受動的な業務ではなく、その実行結果が主業務サービスの意思決定に影響を与えます。

上記の内容は、https://seata.io/zh-cn/blog/tcc-mode-applicable-scenario-analysis.html?utm_source=gold_browser_extension から参照されています。

TCCトランザクションモードの実装

前回の記事では、シータのATモードについて紹介しました。よくわからない場合は、次の記事をお読みください: 7 つの分散トランザクションソリューションを比較すると、私は依然として Alibaba のオープンソース Seata を好みます。これは本当に優れています。（原理＋実践）

もちろん、Seata がサポートするトランザクションモードは AT モードに限定されず、TCC モード、SAGA モード、XA モードも含まれます。以下は TCC モードを統合したものです。

1. デモの様子

電子商取引システムで注文を行う場合を例に挙げてみましょう。デモンストレーションのために、アカウントサービスを直接削除し、注文サービスと在庫サービスを例として使用します。

具体的なロジックは次のとおりです。

クライアントは注文配置インターフェースを呼び出す
在庫の減額
注文を作成する
リクエストが完了しました

上記のロジックによれば、注文サービスは間違いなくメインのビジネスサービスであり、トランザクションの開始者であり、在庫サービスはスレーブビジネスサービスであり、トランザクションの意思決定に参加します。

Seata の AT モードソリューションの疑似コードは次のとおりです。

 @グローバルトランザクション
パブリックResult<Void> createOrder(Long productId,Long num,.....){
    //1.在庫を差し引く
    ストレージを削減します。
    //2.注文を作成する
    順序を保存します。
 }

@GlobalTransactional アノテーションは、グローバルトランザクションを開始するために使用されます。

ただし、AT モードには次のような制限があります。

パフォーマンスが悪く、リソースのロックが長時間に及ぶ
アプリケーション間のトランザクションを解決できません

したがって、パフォーマンスが求められる注文配置インターフェースの場合、TCC モードを使用して実行を 2 つのステージに分割することを検討できます。これにより、プロセス全体がリソースをロックする時間が短縮され、パフォーマンスが向上します。

TCC モードは次のように分割されます。

1) 1段階トライ操作

TCC モデルの Try ステージは、実際にはリソースを予約するためのものです。このプロセス中、必要な数量の商品の在庫が凍結される可能性があるため、在庫テーブルで凍結在庫フィールドを維持する必要があります。

疑似コードは次のとおりです。

 @トランザクション
パブリックブール型try(){
  //在庫を凍結する
  凍結されたストレージ();
  //注文を生成し、ステータスは確認待ちです
  順序を保存します。
 }
 「

注: @Transactional はローカルトランザクションを開きます。例外が発生する限り、ローカルトランザクションはロールバックされ、第 2 フェーズのキャンセル操作が実行されます。

2) 第2段階確認操作

確認操作は、最初のフェーズの試行操作が成功した後にトランザクションをコミットします。関連する操作は次のとおりです。

試行操作により凍結された在庫を解放する（凍結在庫 - 購入数量）
注文を生成する

疑似コードは次のとおりです。

 @トランザクション
パブリックブール値確認(){
    //try操作で予約された在庫を解放する
    クリーン凍結();
    //注文を変更し、ステータスは完了です
    順序を更新します。
戻る 真実;
 }

注: ここで false が返された場合は、TCC 仕様に従って、確認が完了するまで再試行を続けます。

3) 第2段階キャンセル操作

最初の段階の try 操作で例外が発生した後、cancel 操作が実行されます。リソースをロールバックするために使用されます。関連する操作は次のとおりです。

凍結在庫を復元する（凍結在庫 - 購入数量、在庫 + 購入数量）
注文を削除する

疑似コードは次のとおりです。

 @トランザクション
パブリックブールキャンセル(){
    //try操作で予約された在庫を解放する
    ロールバック凍結();
    //注文を変更し、ステータスは完了です
    delOrder();
戻る 真実;
 }

注: ここで false が返された場合、TCC 仕様に従って、キャンセルが完了するまで再試行を継続する必要があります。

2. TCC取引モデルの3つの異常

TCC トランザクションモデルの実装に伴う 3 つの例外は避けられず、実際の運用では回避する必要があります。

1) 空のロールバック

定義: try メソッドが呼び出されなかったり、try メソッドが正常に実行されなかった場合は、cancel メソッドが実行されてロールバックされます。

それをどう理解すればいいのでしょうか? try メソッドを呼び出さずに cancel メソッドが実行されます。これは理解しやすいですね。リソースが予約されていないため、ロールバックは絶対に不可能です。

try メソッドが正常に実行されなかったとはどういう意味ですか?

最初の段階の try メソッドの疑似コードは前のセクションで確認できます。 try メソッドはローカルトランザクションを開始するため、try メソッドの実行中に例外が発生すると、try メソッドのローカルトランザクションがロールバックされます (ロールバックされるのは cancel メソッドではなく、try メソッドのローカルトランザクションであることに注意してください)。この方法では、try メソッド内のすべての操作がロールバックされ、cancel メソッドを呼び出す必要がなくなります。

しかし実際には、try メソッドが例外をスローすると、ロールバックするために cancel メソッドを呼び出す必要があり、その結果、空のロールバックが発生します。

解決：

解決ロジックは非常にシンプルです。cancel メソッドが操作を実行する前に、try メソッドが正常に実行されたかどうかを知る必要があります。

2) 冪等性

TCC モード定義には、確認またはキャンセルメソッドが失敗した場合は、成功するまで再試行を続けると記載されています。

これにはべき等性が関係します。確認メソッドとキャンセルメソッドは、同じグローバルトランザクション内での冪等性を保証する必要があります。

解決：

解決ロジックは非常に単純です。べき等性に対処するには、べき等性フラグを使用して繰り返し操作を防ぐのが自然です。

3) サスペンション

トランザクションコーディネータが TCC サービスの第 1 段階の Try 操作を呼び出すと、ネットワークの輻輳によりタイムアウトが発生する可能性があります。このとき、トランザクションマネージャーは第 2 段階のロールバックをトリガーし、TCC サービスのキャンセル操作を呼び出します。キャンセル呼び出しはタイムアウトしません。

その後、ネットワーク上で輻輳した第 1 段階の Try データパケットが TCC サービスによって受信され、第 1 段階の Try 要求の前に第 2 段階の Cancel 要求が実行されます。遅い Try を実行した後、この TCC サービスは第 2 段階の Confirm または Cancel を受信できず、TCC サービスがハングします。

解決：

解決ロジックは非常にシンプルです。リソースを操作する try メソッドを実行する前に、cancel メソッドが実行されたかどうかを判断します。同様に、キャンセルメソッドを実行した後は、実行ステータスを記録する必要があります。

4) まとめ

上記の 3 つの例外に対しては、各トランザクションのすべての実行段階を記録するトランザクションステータステーブルを維持するなど、実用的な解決策が多数あります。

冪等性: 確認またはキャンセルを実行する前に、トランザクションステータステーブルをチェックして、現在のグローバルトランザクションが確認またはキャンセルメソッドを実行したかどうかを確認します。
空のロールバック: キャンセルを実行する前に、トランザクションステータステーブルを照会して、現在のグローバルトランザクションが正常に実行されたかどうかを確認できます。
中断: try メソッドを実行する前に、トランザクションステータステーブルを照会して、現在のグローバルトランザクションが cancel メソッドを実行したかどうかを確認します。

シータはTCCを統合して達成

プロジェクトを構築して依存関係を追加する方法については詳しく説明しません。まだよく知らない方は、私の以前の記事「7 つの分散トランザクションソリューションを比較した結果、私はやはり Alibaba のオープンソース Seata を好みます。これは本当に優れています!」をお読みください。（原理＋実践）

このセクションではキーコードのみを紹介します。結局、長さには限りがあります。その他の部分のソースコードをダウンロードしてください。

ソースコードディレクトリは次のとおりです。

ソースコードディレクトリ

プロジェクトを開始するために必要な関連文書は次のとおりです。

nacos ディレクトリ内の SEATA_GROUP は、Seata トランザクションサーバーおよびクライアントに必要な関連構成であり、nacos に直接インポートできます。

seataディレクトリのconfは1.3.0バージョンサーバーの設定です

SQL カタログは複数のデータベースに関連しています。

1. TCCインターフェース定義

order-boot モジュールで OrderTccService を作成します。コードは次のとおりです。

コード内のコメントはすでに非常に充実していますが、ここではいくつかの重要なポイントを紹介します。

@LocalTCC: このアノテーションはTCCトランザクションを有効にします
@TwoPhaseBusinessAction: このアノテーションは try メソッドにアノテーションが付けられます。その 3 つの属性は次のとおりです。
- name: TCCトランザクションの名前。一意である必要があります。
- commitMethod: 確認メソッドの名前。デフォルトは commit です。
- rollbackMethod: キャンセルメソッドの名前。デフォルトはrollbackです。
特に、confirmとcancelの戻り値は重要です。 false が返された場合、システムは継続的に再試行します。

2. TCCインターフェースの実装

定義ができたので、次のように実装する必要があります。

1) tryメソッド

メソッドを試す

①のコードは例外のハングを防ぐためのものです。トランザクションログテーブルからグローバルトランザクション ID のステータスを取得します。キャンセル状態の場合は実行されません。

②のコードは在庫を凍結する

③のコードで注文が生成され、ステータスは確認待ちになります

④のコードは、キーが現在のクラスとグローバルトランザクションID、値が現在のタイムスタンプであるタグをべき等ツールクラスに追加します。

注: ローカルトランザクションを有効にする必要があります。上記のコードでは、@Transactional を使用してローカルトランザクションを有効にします。

2) 確認方法

確認方法

①のコードは、現在のクラスとグローバルトランザクションIDに従って、べき等ツールクラスから値を取得します。 try フェーズが正常に実行された場合は値が追加され、confirm メソッドが正常に実行された場合は値が削除されるため、confirm の開始時に値が存在するかどうかを判断することで、べき等効果が実現され、再試行を防ぐことができます。

⑥のコードは、tryメソッドで追加された値をべき等ユーティリティクラスの外に移動します。

②のコードは、BusinessActionContextからtryメソッドの入力パラメータを取得します。

③のコードは凍結された在庫を解放するためのものです

④のコードは注文のステータスを完了に変更します。

注意: 1. ローカルトランザクションを有効にします。2. 戻り値に注意してください。 false が返された場合、プロセスは再試行されます。

3) キャンセル方法

キャンセル方法

①のコードは、トランザクションログテーブルにデータを挿入し、現在のトランザクションがキャンセルメソッドに入っていることをマークして、ハングアップを防止します。これはtryメソッドの①のコードに相当します。

②のコードは、べき等性ツールクラス内の対応する現在のクラスとグローバルトランザクションIDでtryメソッドが正常に実行された場合にのみ値が格納されるため、べき等性と空のロールバックを防ぐためのものです。これにより、冪等性と空のロールバックの両方が防止されます。

③のコードは凍結された在庫を復元します。

④のコードはこの注文を削除します

⑤のコードは、べき等ツールクラスの現在のクラスとグローバルトランザクションIDに対応する値を削除します。

3. TCC モデルの 3 つの異常をどのように防ぐか?

実装方法は多数あります。場合によっては、現在のステータスがトランザクションログテーブルに完全に記録され、べき等性、空のロールバック、中断の問題が完全に解決されます。

便宜上、Chen は次の 2 つのソリューションを使用しました。

1) 冪等性と空のロールバック

冪等ツールクラスが使用されます。このクラスには、キーが現在のクラスとグローバルトランザクション ID で、値がタイムスタンプであるマップが含まれています。

コードは次のとおりです。

考え方は次のとおりです。

tryメソッドの最後に、べき等ツールクラスのaddメソッドを使用して値を追加します。
べき等ツールクラスの削除メソッドを使用して、確認メソッドとキャンセルメソッドの値を削除します。
確認メソッドとキャンセルメソッドでは、べき等ツールクラスの get メソッドを使用して値を取得します。空の場合は実行されたことを意味し、直接 true が返されます。これにより、冪等性と空のロールバックの両方が防止されます。

2. サスペンション

サスペンションの実装はトランザクションログテーブルに依存しており、テーブル構造は次のとおりです。

作成する テーブル`transactional_record` (
  `id`ビッグイント(11) NOT   NULL AUTO_INCREMENT、
  `xid` varchar (100) ではない  NULL 、
  `status` int (1)デフォルト  NULLコメント'1.試す 2 コミット 3 キャンセル ' 、
主要な  BTREE を使用したキー(`id`)
 ) エンジン=InnoDBデフォルト文字セット=utf8mb4;