5つの分散トランザクションソリューションを比較すると、私は依然としてAlibabaのSeata（原則+実践）を好む

[[354367]]

この記事はWeChatの公開アカウント「Programmer's Insider Things」から転載したもので、著者はProgrammer's Insider Thingsです。この記事を転載する場合は、Programmer Insider 公式アカウントまでご連絡ください。

長い間投稿していませんでした。最近とても忙しいです。父親になって43日目です。肉体的にも精神的にも疲れています。年末だったため、会社はKPIを達成するために技術部門に10時までの残業を強制していました。夜になると、子供は2、3時間おきに起きてしまうので、基本的にぐっすり眠る機会はありませんでした。彼は毎日ぼんやりしており、時々奇妙な発疹も出るので、私たちはいつも心配していました。

記事を書くための限られた時間は無限に分割されます。あぁ〜働くって本当に大変ですね。

その小さな表情は何を意味しているのでしょうか？

最初は何を書いていいか分かりませんでしたが、たまたま分散トランザクションに Alibaba の Seata ミドルウェアを使用するという新しいプロジェクトが手元にあったので、実践を共有します。

Seata を紹介する前に、分散トランザクションの基本的な概念を簡単に確認しましょう。

分散トランザクションの生成

まず、Baidu の分散トランザクションの定義を見てみましょう。分散トランザクションとは、参加者、トランザクションをサポートするサーバー、リソースサーバー、およびトランザクションマネージャーが異なる分散システムの異なるノードに配置されているトランザクションを指します。

え〜とちょっと抽象的ですね。理解するために簡単な絵を描いてみましょう。注文を受けて在庫を減らし、残高を差し引く例を見てみましょう。

システムが小さい場合、モノリシックアーキテクチャは既存のビジネスニーズを完全に満たすことができます。すべてのビジネスがデータベースを共有し、注文プロセス全体では、1 つの方法と同じトランザクションでデータベースを操作するだけで済む場合があります。この時点で、すべての操作をコミットするか、すべての操作をロールバックするのは簡単です。

サブライブラリとサブテーブル、SOA

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

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

シータの利点

分散トランザクションを実装するためのソリューションは数多くあり、XA プロトコルに基づく 2PC や 3PC、ビジネスレイヤーに基づく TCC、メッセージキュー + メッセージテーブルを適用して実装される最終的な一貫性ソリューション、そして今日説明する Seata ミドルウェアなどがあります。それぞれのソリューションの長所と短所を見てみましょう。

2PC

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

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

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

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

3PC

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

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

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

TCC

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

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

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

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

メッセージトランザクション（結果整合性）

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

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

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

シータ

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

Seata は 2 段階のサブミッションなので、各段階で何が行われるか見てみましょう。以下では、注文から在庫と残高を差し引く例も取り上げます。

まず、Seata 分散トランザクションのいくつかの役割を紹介します。

トランザクションコーディネーター (TC): グローバルトランザクションコーディネーター。グローバルトランザクションと各ブランチトランザクション (異なるサービス) のステータスを調整し、グローバルトランザクションと各ブランチトランザクションのロールバックまたはコミットを実行するために使用されます。
トランザクションマネージャー™: トランザクションマネージャーは、ビジネスレイヤーで全体的なトランザクションを開始/コミット/ロールバックするために使用されます (アノテーションを使用して、サービスを呼び出すメソッドでトランザクションを開始します)。
リソースマネージャー (RM): 一般的に、ブランチトランザクションを表すビジネスデータベースを指します。ブランチトランザクションを管理し、TC と調整してブランチトランザクションを登録し、ブランチトランザクションのステータスを報告し、ブランチトランザクションのコミットまたはロールバックを実行します。

Seata は分散トランザクションを実装し、重要な役割 UNDO_LOG (ロールバックログレコードテーブル) を設計します。このテーブルは、各アプリケーションの分散トランザクションのビジネスライブラリに作成されます。このテーブルの中心となる機能は、更新前後の業務データのデータミラーリングをロールバックログに整理し、UNDO_LOG テーブルにバックアップして、業務上の異常をいつでもロールバックできるようにすることです。

フェーズ1

たとえば、以下ではユーザーテーブルの名前フィールドを更新します。

アップデート ユーザー セット 名前= 'シャオフーは最もハンサム'  どこ 名前= 'プログラマーのインサイダー'

まず、Seata の JDBC データソースエージェントは、ビジネス SQL を解析して SQL メタデータを抽出します。つまり、SQL タイプ (UPDATE)、テーブル (ユーザー)、条件 (名前 = 'Programmer') などの関連情報を取得します。

第一段階のフローチャート

まず、データフロントミラーをクエリし、解析によって取得した条件情報に基づいてクエリステートメントを生成し、データの一部を検索します。

選択  名前 から ユーザー どこ 名前= 'プログラマーのインサイダー'

データフロントミラー

次に、ビジネスSQLを実行して、フロントミラーデータの主キーに基づいてバックミラーデータをクエリします。

選択 名前 から ユーザー ここで、 id = 1

データバックミラー

更新前後の業務データのデータミラーをロールバックログに整理し、業務データの更新ログとロールバックログを同じローカルトランザクションでコミットし、それぞれ業務テーブルと UNDO_LOG テーブルに挿入します。

ロールバックレコードのデータ形式は次のとおりです: afterImage (前イメージ)、beforeImage (後イメージ)、branchId (ブランチトランザクションID)、xid (グローバルトランザクションID)

 {
 「ブランチID」 :641789253、
 「xid」 : 「xid:xxx」 、
 「元に戻すアイテム」 :[
        {
 「後イメージ」 : {
 「行」 :[
                    {
 「フィールド」 :[
                            {
 「名前」 : 「ID」 、
 「タイプ」 : 4,
 「値」 :1
                            }
                        ]
                    }
                ]、
 "テーブル名" : "製品"  
            },
 「前画像」 :{
 「行」 :[
                    {
 「フィールド」 :[
                            {
 「名前」 : 「ID」 、
 「タイプ」 : 4,
 「値」 :1
                            }
                        ]
                    }
                ]、
 "テーブル名" : "製品"  
            },
 "sqlType" : "更新"  
        }
    ]
 }

これにより、送信されたビジネスデータの更新には必ず対応するロールバックログが必要になります。

ローカルトランザクションをコミットする前に、各ブランチトランザクションは、ブランチ (ブランチ ID) をグローバルトランザクションコーディネーター TC に登録し、変更するレコードのグローバルロックを申請する必要があります。このデータをロックするには、SELECT FOR UPDATE ステートメントを使用します。ロックを取得できない場合は、ローカルトランザクションをロールバックする必要があります。 TM がトランザクションを開始すると、グローバルに一意の XID が生成され、呼び出された各サービス間で渡されます。

このようなメカニズムにより、グローバルトランザクションの最初のフェーズでローカルトランザクションブランチ (Branch Transaction) をコミットし、ローカルトランザクションによってロックされたリソースを即座に解放することができます。第 2 フェーズでリソースを解放する従来の XA トランザクションと比較して、Seata はロック範囲を削減し、効率を向上させます。第 2 フェーズで例外が発生し、ロールバックする必要がある場合でも、対応するロールバックデータを UNDO_LOG テーブルからすばやく見つけて、SQL に逆解析し、ロールバック補正を実現できます。

最後に、ローカルトランザクションがコミットされ、更新されたビジネスデータと以前に生成された UNDO LOG データが一緒にコミットされ、ローカルトランザクションの送信結果がグローバルトランザクションコーディネーター TC に報告されます。

第二段階

2 番目の段階では、各ブランチの解決に基づいてコミットまたはロールバックを実行します。

解決がグローバルコミットの場合、各ブランチトランザクションはコミットされて成功し、グローバルトランザクションコーディネーター (TC) はブランチに第 2 フェーズの要求を送信します。 TC からブランチ送信要求を受信すると、要求は非同期タスクキューに配置され、送信成功結果がすぐに TC に返されます。非同期キューは、ブランチ ID に基づいて、対応する UNDO LOG ロールバックレコードを非同期かつバッチで検索して削除します。

解決がグローバルロールバックの場合、プロセスはグローバルコミットよりも少し複雑になります。 RM サービスは、TC グローバルコーディネータからロールバック要求を受信し、XID とブランチ ID を通じて対応するロールバックログレコードを見つけ、ロールバックレコードを通じて逆更新 SQL を生成して実行し、ブランチのロールバックを完了します。

注意: ローカルビジネストランザクションの実行後、ロールバックログレコード操作を削除する必要があります。

複数の分散トランザクションの利点と欠点については上記で説明しました。分散トランザクションの途中でSeataを実践して体感してみましょう。

シータプラクティス

Seata は独立して導入する必要があるミドルウェアなので、まずは Seata Server をセットアップします。ここでは、最新バージョンの seata-server-1.4.0 を例に説明します。ダウンロードアドレス: https://seata.io/en-us/blog/download.html

ファイルを解凍した後は、\seata\conf ディレクトリ内の file.conf ファイルと registry.conf ファイルのみに注意する必要があります。

Seata サーバー

ファイル.conf

file.conf ファイルは、永続的なトランザクションログのモードを構成するために使用されます。現在、file、db、redis の 3 つのモードが提供されています。

file.conf ファイルの設定

注: db モードを選択した後、対応するデータベースに 3 つのテーブルを作成する必要があります: globalTable (永続的なグローバルトランザクション)、branchTable (送信された各ブランチの永続的なトランザクション)、および lockTable (リソースをロックする各ブランチの永続的なトランザクション)。

 -- GlobalSessionデータを保存するテーブル 
 -- 永続的なグローバルトランザクション 
作成する テーブルが存在しない場合`global_table`
 （
    `xid` VARCHAR (128)ではない  NULL 、
    `transaction_id` BIGINT 、
    `status` TINYINT NOT   NULL 、
    `application_id` VARCHAR (32)、
    `transaction_service_group` VARCHAR (32)、
    `トランザクション名` VARCHAR (128)、
    `タイムアウト` INT ,
    `begin_time` BIGINT 、
    `application_data` VARCHAR (2000)、
    `gmt_create` 日付時刻、
    `gmt_modified` 日付時刻、
主要な キー(`xid`)、
キー`idx_gmt_modified_status` (`gmt_modified`, `status`),
キー`idx_transaction_id` (`transaction_id`)
 ) エンジン = InnoDB
デフォルト文字セット = utf8; 
 
 -- BranchSessionデータを保存するテーブル 
 --各コミットブランチのトランザクションを永続化する 
作成する テーブルが存在しない場合`branch_table`
 （
    `branch_id` BIGINT        ない  NULL 、
    `xid` VARCHAR (128)ではない  NULL 、
    `transaction_id` BIGINT 、
    `resource_group_id` VARCHAR (32)、
    `resource_id` VARCHAR (256)、
    `branch_type` VARCHAR (8)、
    `ステータス` TINYINT、
    `client_id` VARCHAR (64)、
    `application_data` VARCHAR (2000)、
    `gmt_create` 日付時刻(6)、
    `gmt_modified` 日付時刻(6)、
主要な キー(`branch_id`)、
キー`idx_xid` (`xid`)
 ) エンジン = InnoDB
デフォルト文字セット = utf8; 
 
 -- ロックデータを保存するテーブル 
 -- 各ブランチロックテーブルトランザクションを永続化する 
作成する テーブルが存在しない場合`lock_table`
 （
    `row_key` VARCHAR (128) NOT   NULL 、
    `xid` VARCHAR (96)、
    `transaction_id` BIGINT 、
    `branch_id` BIGINT        ない  NULL 、
    `resource_id` VARCHAR (256)、
    `テーブル名` VARCHAR (32)、
    `pk` VARCHAR (36)、
    `gmt_create` 日付時刻、
    `gmt_modified` 日付時刻、
主要な キー(`行キー`)、
キー`idx_branch_id` (`branch_id`)
 ) エンジン = InnoDB
デフォルト文字セット = utf8;

レジストリ.conf

registry.conf ファイルは、レジストリセンターと構成センターを設定します。

現在、登録センターは、nacos、eureka、redis、zk、consul、etcd3、sofa の 7 種類をサポートしています。ここでは登録センターとして eureka を使用します。構成センターは、nacos、apollo、zk、consul、etcd3 の 5 つのタイプをサポートしています。

registry.conf ファイルの設定

設定が完了したら、\seata\bin ディレクトリで seata-server を起動すると、Seata サーバーがセットアップされます。

シータクライアント

Seata Server 環境が構築されたら、order-server (注文サービス)、storage-server (在庫控除サービス)、account-server (口座金額サービス) の 3 つの新しいサービスを作成し、それぞれ eureka に登録します。

各サービスの一般的なコア構成は次のとおりです。

春：
    応用：
名前: ストレージサーバー
    雲：
        アリババ:
            シータ:
                tx-サービス-グループ: my_test_tx_group
    データソース:
        ドライバークラス名: com.mysql.jdbc.Driver
        URL: jdbc:mysql://47.93.6.1:3306/seat-storage
        ユーザー名: root
パスワード: root 
 
 # ユーレカレジストリ
ユーレカ：
    クライアント：
        サービス URL:
            デフォルトゾーン: http://${eureka.instance.hostname}:8761/eureka/
    実例：
        ホスト名: 47.93.6.5
        優先IPアドレス: true

一般的なビジネスプロセスは次のとおりです。ユーザーが注文要求を開始し、ローカル注文サービスが注文レコードを作成し、RPC を介してリモートでストレージ控除在庫サービスとアカウント控除残高サービスを呼び出します。 3 つのサービスが同時に正常に実行された場合にのみ、注文プロセスが完了します。サービスの実行に失敗した場合、他のすべてのサービスはロールバックされます。

Seata はビジネスコードに非常に干渉します。コード内でこれを使用するには、@GlobalTransactional アノテーションを使用してグローバルトランザクションを開始するだけです。

 @オーバーライド
@GlobalTransactional( name = "create-order" 、 rollbackFor = Exception.class)
パブリックvoid create (注文 注文） { 
 
    文字列 xid = RootContext.getXID(); 
 
    LOGGER.info( "------->トランザクションが開始されました" );
    //ローカルメソッド
    orderDao.create (注文) ; 
 
    //在庫を減算するリモートメソッド
    storageApi.decrease( order .getProductId(), order .getCount()); 
 
    //口座残高を差し引くリモートメソッド
    LOGGER.info( "------->口座引き落とし注文開始" );
    accountApi.decrease( order .getUserId(), order .getMoney());
    LOGGER.info( "------->注文を終了するためにアカウントから引き落としています" ); 
 
    LOGGER.info( "------->トランザクションが終了しました" );
    LOGGER.info( "グローバルトランザクションxid: {}" , xid);
 }

前述したように、Seata AT モードは分散トランザクションを実装します。データロールバックログを保存するには、関連するビジネスライブラリに undo_log テーブルを作成する必要があります。テーブル構造は次のとおりです。

 -- AT モードの場合、ビジネス データベース用にこの SQL を初期化する必要があります。 seata サーバーではそれは必要ありません。  
作成する テーブルが存在しない場合`undo_log`
 （
    `id` BIGINT (20) NOT   NULL AUTO_INCREMENT COMMENT '増分ID' ,
    `branch_id` BIGINT (20) NOT   NULL COMMENT 'ブランチトランザクションID' 、
    `xid` VARCHAR (100)ではない  NULL COMMENT 'グローバルトランザクションID' 、
    `context` VARCHAR (128) NOT   NULL COMMENT 'undo_logコンテキスト（シリアル化など）' 、
    `rollback_info` LONGBLOB NOT   NULLコメント「ロールバック情報」 、
    `log_status` INT (11) NOT   NULL COMMENT '0:通常状態、1:防御状態' 、
    `log_created` 日付時刻NOT   NULLコメント'create datetime' 、
    `log_modified` 日付時刻NOT   NULLコメント'datetimeの変更' 、
主要な キー(`id`)、
個性的 キー`ux_undo_log` (`xid`, `branch_id`)
 ) エンジン = InnoDB
  AUTO_INCREMENT = 1
デフォルト文字セット = utf8 コメント = 'AT トランザクション モード undo テーブル' ;

環境設定の作業はこれで完了です。完全なケースは後で GitHub に投稿される予定なので、ここではスペースを取りません。

シータのテスト

プロジェクト内のサービス呼び出しプロセスは次のとおりです。

サービスコールプロセス

各サービスを開始した後、注文インターフェースを直接要求して効果を確認します。注文テーブルが正常にレコードを作成し、保管在庫テーブルの使用フィールドの数が増加し、口座残高テーブルの使用フィールドの数が増加している限り、注文プロセスが成功したことを意味します。

生データ

リクエスト後の転送プロセスは正常であり、データは期待どおりです

注文データ

そして、TMトランザクションマネージャのオーダーサーバーサービスのコンソールにも2フェーズコミットのログが出力されていることがわかりました。

コンソールが2回送信

それでは、いずれかのサービスに異常がある場合、正常にロールバックされるかどうかを確認しましょう。アカウントサーバーサービスでタイムアウト例外をシミュレートして、グローバルトランザクションをロールバックできるかどうかを確認します。

グローバルトランザクションのロールバック

すべてのデータが正常に実行されなかったことが判明しましたが、これはグローバルトランザクションのロールバックも成功したことを示しています。

undo_log ロールバックレコードテーブルの変更を見てみましょう。 Seata はロールバックログを非常に速く削除するため、テーブル内のロールバックログを確認するには、特定のサービスにブレークポイントを設定して、より明確に確認する必要があります。

ロールバックレコード

要約する

上記では、2PC、3PC、TCC、MQ、Seata の 5 つの分散トランザクションソリューションについて簡単に紹介し、Seata ミドルウェアの実装についても詳しく説明しました。しかし、どのソリューションを選択する場合でも、プロジェクトに適用する際には注意が必要です。データの一貫性が強い特定のシナリオを除き、可能であれば使用を避ける必要があります。なぜなら、どれだけパフォーマンスが優れていても、プロジェクトが分散トランザクションで覆われると、全体的な効率は数倍低下し、特に同時実行性の高い状況ではそのデメリットが顕著になるからです。

この場合の github アドレス: https://github.com/chengxy-nds/Springboot-Notebook/tree/master/springboot-seata-transaction

<<: SD-WAN 業界を理解する: WAN クラウド化の観点から SD-WAN を見る

>>: ガベージコレクションについて話しましょう。