Seata 2.6.0 の AT 分散トランザクション：デプロイから組み込み、障害の境界まで
本文は Seata 2.6.0、Spring Boot 3、Spring Cloud Alibaba の対応バージョン、MySQL 8 を前提に説明します。Seata、Spring Boot、Spring Cloud Alibaba、Nacos、およびクライアント依存関係は公式の互換性マトリクスに従って組み合わせる必要があります。どれか 1 つだけをアップグレードしてはいけません。
まず結論
Seata AT は、1 回の業務処理で複数のリレーショナルデータベースを変更し、参加側が短時間のグローバルロック競合を許容でき、最終整合性より強いロールバックセマンティクスが必要なケースに適しています。
AT は「すべての分散操作を自動的にロールバックする」ものではありません。送信済みのメッセージ、呼び出し済みのサードパーティ API、書き込み済みのキャッシュを自動で取り消すことはできません。また、冪等性、リトライ、補償処理、確実なメッセージ配信を置き換えるものではありません。
主な流れは次のとおりです。
一、コンポーネントと用語
- TC（Transaction Coordinator）：グローバルトランザクション、ブランチトランザクション、グローバルロックを保持します。
- TM（Transaction Manager）：グローバルトランザクションの開始、コミット、ロールバックを担当します。
- RM（Resource Manager）：ブランチの登録、結果の報告、ローカルロールバックの実行を担当します。
Seata クライアントには通常、TM と RM の両方が含まれます。
订单服务（TM + RM）
-> 库存服务（RM）
-> 账户服务（RM）
|
v
Seata TC
@GlobalTransactional は通常、グローバルトランザクションのエントリーポイントに置くのが一般的です。参加するサービスで新たなグローバルトランザクションを開始する必要はありません。ただし、対象データベースを使う各参加サービスでは、Seata のデータソースプロキシが正しく適用されている必要があります。
二、AT の実際の実行プロセス
1 件の UPDATE を例にすると、RM はローカルトランザクションの中でおおむね次の処理を行います。
- SQL を解析し、表、主キー、変更対象範囲を特定します。
- 変更前イメージ（before image）を取得します。
- 業務 SQL を実行します。
- 変更後イメージ（after image）を取得します。
- undo_log に書き込みます。
- ブランチトランザクションを登録し、ローカルトランザクションをコミットします。
グローバルコミット時、TC は各ブランチにコミットを通知します。第 1 フェーズでローカルコミットは完了しているため、第 2 フェーズでは主に undo_log の非同期クリーンアップを行います。
グローバルロールバック時、RM は undo_log を読み込み、現在のデータが after image と一致するかを検証します。そのうえで before image に基づいて逆操作を生成し、ローカルトランザクション内でロールバックを実行します。
つまり、AT はデータベースのスナップショットでも、固定的な逆操作 SQL でもありません。SQL 解析、前後のイメージ、undo_log、グローバルロックに依存しています。
三、Seata 2.6.0 のデプロイ原則
現在の参照バージョンは Seata 2.6.0 です。latest は使わず、Seata 1.x の設定ファイル、フィールド、データベーススクリプトを 2.x に直接コピーしないでください。
学習環境では、TC の登録方式を file、ストレージモードを file にして、まず業務フローを検証できます。本番環境では通常、Nacos などの登録センターと設定センターを使い、データベースまたは公式がサポートする高可用ストレージを採用することが望ましいです。
TC が store.mode=db を使う場合は、Seata 2.6.0 のリリースパッケージにある対応データベースディレクトリの MySQL スクリプトを実行してください。スクリプトには少なくとも次が含まれます。
global_table 全局事务
branch_table 分局事务
lock_table 全局锁
distributed_lock TC 集群协调
vgroup_table 事务组映射
AT に参加する各業務データベースにも、同じバージョンのクライアントに対応する undolog テーブルのスクリプトを実行する必要があります。TC のテーブルと業務データベースの undolog は別の種類のテーブルです。
AT データソースには通常、次の条件が必要です。
- MySQL で InnoDB を使用すること
- 業務テーブルに安定した主キーがあること
- SQL を Seata が解析できること
- データベースアカウントに undo_log を作成・書き込みする権限があること
- undo_log、業務 SQL、ローカルトランザクションを同じデータベース接続境界で処理すること
Docker イメージ、JDK、クライアント依存関係、データベーススクリプトは、相互に互換性のある組み合わせにする必要があります。本番環境では、TC の管理用ポートをインターネットへ公開しないでください。
四、Spring Boot クライアントの組み込み
依存バージョンは、それぞれ独立したバージョン番号を手入力して組み立てるのではなく、Spring Boot、Spring Cloud、Spring Cloud Alibaba、Seata の互換性マトリクスに基づいて BOM や dependency management を使ってください。
設定の考え方は次のとおりです。実際のプロパティ名は、現在のクライアントバージョンの設定メタデータを参照してください。
seata:
enabled: true
tx-service-group: order_tx_group
enable-auto-data-source-proxy: true
data-source-proxy-mode: AT
Nacos を使う場合、登録センターと設定センターの両方で、server-addr、namespace、group、username、password を明示的に設定してください。資格情報は環境変数または secret から注入し、Git にコミットしないでください。
起動後は次の点を確認してください。
- Seata クライアントが初期化されている
- データソースが Seata のプロキシになっている
- RM が TC に登録されている
- TM が TC に登録されている
- トランザクショングループが利用可能な TC クラスタにマッピングされている
複数のデータソースがある構成では、自動設定だけに頼らず、各データソースのプロキシ、Mapper スキャン、トランザクションマネージャーを明示的に検証してください。
五、業務例
グローバルエントリ：
参加サービスはローカル業務を担当します。
重要なのはアノテーションの数ではなく、境界です。
- グローバルエントリでは @GlobalTransactional を使う
- 対象データベースのローカル操作には明確なトランザクションがある
- リモート呼び出しが失敗した場合、識別可能な例外をスローする
- 在庫の減算と口座からの引き落としは冪等である
- リトライによって在庫や口座残高を二重に減算しない
HTTP、RPC、メッセージキューを使う場合は、XID が伝播することを確認してください。入口でアノテーションを付けるだけで XID を伝播させないと、参加サービスは同じグローバルトランザクションに参加しません。
六、AT の失敗範囲
次の SQL は重点的に検証してください。
- 複雑な JOIN、サブクエリ、バッチ更新
- 主キーがない表
- 主キーまたはパーティションキーの更新
- 大規模データ更新
- ストアドプロシージャ、トリガー、データベース固有の構文
- 長時間トランザクションと競合の激しいホット行
ビジネスメソッドが成功を返すだけでは不十分です。障害注入テストによって、ロールバック結果、ロックの解放、undo_log のクリーンアップを確認してください。
AT は外部副作用をカバーしません。
数据库提交 -> 发送 MQ 消息 -> 调用支付接口 -> 写入 Redis
どの手法が適切かは業務に応じて判断し、Outbox、ローカルメッセージテーブル、確実なメッセージ配信、冪等な消費、状態マシン、補償トランザクション、TCC、Saga から選んでください。
グローバルロックも無料の機能ではありません。人気商品、アカウント、在庫ではロック競合が発生し、分岐登録の遅延、トランザクションの待ち時間、ロールバックの遅延、スレッドプールの滞留につながります。トランザクションを短くし、トランザクション中の不要なリモート呼び出しを避け、リソースを安定した順序で更新し、ロック待ちとロールバックのリトライを監視してください。
七、障害テストのチェックリスト
少なくとも次のケースをテストしてください。
- 在庫サービスがタイムアウトする。
- アカウントサービスが業務エラーを返す。
- 1 つのブランチでローカルコミットした後に、別のブランチが失敗する。
- TC が再起動する。
- データベース接続プールが枯渇する。
- after image の検証に失敗する。
- 重複リクエストとクライアントのリトライが発生する。
- ネットワーク応答が失われる。
- サービスリリース時にバージョン互換性の問題が発生する。
毎回、次の項目を確認します。
业务表最终状态
global_table
branch_table
lock_table
undo_log
日志中的 XID
本番ログでは、リクエスト、データベースブランチ、リモート呼び出し、例外ログで XID を一貫して出力してください。ただし、パスワード、token、機密性の高い業務データは出力しないでください。
八、本番環境のチェックリスト
- Seata Server、クライアント、Spring Boot、Spring Cloud Alibaba のバージョンが互換性を持つこと。
- すべてのイメージと依存関係を固定バージョンにすること。
- TC は高可用構成でデプロイし、本番環境の障害復旧に file ストレージを使わないこと。
- Nacos、データベース、TC への通信を内網経由にすること。
- 設定と資格情報は secret または外部設定から注入すること。
- 各業務データベースに、対応バージョンの undo_log を用意すること。
- TC データベースをバックアップし、クリーンアップ方針を設けること。
- グローバルトランザクションにタイムアウト、リトライ、デグレード戦略を持たせること。
- 外部副作用に冪等性または補償策を用意すること。
- XID、トランザクション時間、ロールバック率、ロック待ち、タイムアウト、リトライ、undo_log 件数を監視すること。
九、AT を使わない方がよい場合
次の場合は、通常还有其他手法を検討する必要があります。
- トランザクションがメッセージ、決済、ファイル、サードパーティ API にまたがる場合
- 1 つのグローバルトランザクションが長時間続く場合
- ホット行の競合が激しい場合
- SQL を安定して解析できない、または主キーがない場合
- 最終整合性の方が業務に合う場合
- チームに TC、データベーススクリプト、監視、障害演習を維持する体制がない場合
Seata AT によって、分散システムが単一マシンのトランザクションに変わるわけではありません。Seata AT は、適切なデータベース境界の中で、自動的な協調と補償の仕組みを提供します。正しく使うには、境界を明確にし、バージョンを固定し、トランザクションを短く保ち、失敗経路を実際にテストすることが前提です。
参考資料
- Seata 公式リポジトリと v2.6.0 Release
- Seata AT Mode 公式ドキュメント
- Seata 2.6.0 用のデータベーススクリプト
- Spring Boot、Spring Cloud Alibaba 公式互換性マトリクス
- Nacos 公式のデプロイ・認証ドキュメント
最終レビュー日時：2026-07。