Seataの4つのモード比較まとめ｜Spring Cloud 59

I.はじめに

次の一連の章を通して説明します。

docker-compose は Seata Server の高可用性デプロイメントを実装します | Spring Cloud 51

Seata AT モード理論の研究、トランザクション分離と部分的なソースコード分析 | Spring Cloud 52

Spring Boot が Seata を AT モード分散トランザクションと統合する例 | Spring Cloud 53

Seata XA モード理論の学習、使用方法、注意事項 | Spring Cloud54

Seata TCC モード理論の学習、本番レベルの使用例の構築と注意点 | Spring Cloud55

Seata TCC モードでの冪等性、一時停止、空のロールバックの問題を解決する | Spring Cloud56

Seata Saga モード理論の学習、本番レベルの使用例構築と注意点 (1) | Spring Cloud57

Seata Saga モード理論の学習、本番レベルの使用例構築と注意点 (2) | Spring Cloud58

私たちは、理論とSeataそのAT、XA、TCC、およびトランザクション モードSagaの使用法を深く理解しており、Seata今日の分散基本理論と の 4 つのモードを比較して要約します。

二、事務

トランザクションを簡単に理解すると、データベース内のさまざまなデータを更新するプログラムの実行単位 ( ) ですが、unit厳密に言うと、トランザクションには、 と呼ばれる原子性、一貫性、分離性、永続性が必要ですACID。

• アトミック性 ( Atomicity): トランザクション内のすべての操作は実行されるか、または実行されません。

• 一貫性 ( Consistency): 一貫性とは、トランザクションがデータベースをある一貫した状態から別の一貫した状態に変更する必要があること、つまり、データベース処理の前後の結果が、ビジネス ルールに従って実行された後の結果と一貫している必要があることを意味します。

• 分離 ( Isolation): 複数のトランザクションが同時に実行されたときに、相互に干渉しないことを指します。

• 永続性 ( Durability): トランザクションの完了後、データは永続的に保存され、その後の他の操作や失敗はトランザクションの結果に影響を与えないという事実を指します。

3. 分散トランザクション

名前が示すように、分散トランザクションは、複数のローカル トランザクションで構成される分散システムでトランザクションを実装することです。

分散トランザクションを使用する根本的な原因は、同時実行性が高く、サーバーがビジー状態になると、リクエストに応答しやすくするために複数のサーバーを追加する必要があることです。このとき、データのコピーが 1 つしかないという問題が発生します。分散環境で、在庫サービス、注文サービス、およびトランザクションなどの各トランザクションの実行後にデータが正しいことをどのように保証するか。支払いサービス。これらは別々にデプロイされます。この時点では、購入が完了したら、3 つのサービスすべてが、一緒に失敗するか一緒に成功するか、対応する操作を完了する必要があります。これは、分散トランザクションを解決するという問題につながります。

4. CAP理論

分散システムでは、一貫性（ Consistency）、可用性（Availability）、分割耐性（ ）の 3Partition toleranceつの要素は同時に最大 2 点までしか達成できず、3 つすべてを考慮することは不可能です。

• 一貫性 ( Consistency): 分散システム内のすべてのデータ バックアップが同時に同じ値を持つかどうか。(すべてのノードが同じ最新のデータ コピーにアクセスすることに相当)

• 可用性 ( Availability): クラスター内の一部のノードに障害が発生した後でも、クラスター全体がクライアントの読み取りおよび書き込みリクエストに応答できるかどうか。(データ更新の高可用性)

• 分割許容値 (Partition許容値): 実際の効果という点では、分割は通信の時間制限要件と同等です。システムが制限時間内にデータの整合性を達成できない場合は、パーティションが発生したことを意味し、現在の操作について C と A のどちらかを選択する必要があります。

図の重複部分は、分散環境で行う必要があるトレードオフです。 、 、 、CPのAPいずれかですCAが、 は存在しませんCAP。

CP：使いやすさを犠牲にします。レプリケーション同期プロトコルは通常、厳密なクォーラム プロトコル ( Paxos、Raft、ZAB) または2PCプロトコルを使用します。CPシステムのタイプには、、、、などMongoDBがあります。HBaseZookeeperRedisElasticSearch

AP: 一貫性を犠牲にします。レプリケーション同期プロトコルは通常、非厳密なクォーラム プロトコルを使用します。APシステムのタイプにはCouch DB、、、CassandraなどAmazon Dynamoがあります。

CA：話はさておき、RDBMS体系的であると主張する分散システムの中に、Googleと Aliがあります。OracleMySQLCASpannerOceanBase

Q:分散システムでは整合性と可用性の両方を保証できないのはなぜですか?

回答: まず前提がありますが、分散システムの場合、パーティションの耐障害性は最も基本的な要件であるため、基本的に分散システムを設計する際には一貫性 ( C) か可用性 ( ) のどちらかAを選択するしかありません。

整合性が保証されている場合 ( C): ノードN1および のN2場合、N1に、N2その操作を一時停止する必要があり、N1同期データが到着した場合にのみ読み取りおよび書き込みリクエストを行うN2ことができN2、N2その間にクライアントによってリクエストが送信されます。中断された操作は受信失敗またはタイムアウトになります。明らかに、これはユーザビリティとは正反対です。

可用性が保証されている場合 ( A):N2読み取りおよび書き込み操作を一時停止することはできませんが、N1データが同時に書き込まれている場合、これは整合性要件に違反します。

CAPとACIDの合計はまったく異なりAますC。

• C違い：

  • ACID一貫性とはデータベース ルールに関するものであり、データベースは常に、ある一貫した状態から別の一貫した状態に遷移します。

  • CAP一貫性とは、分散マルチサーバー間でデータをレプリケートし、これらのサーバーが同じデータを持つようにすることです。ネットワーク速度の制限により、異なるサーバー上でこのレプリケーションにかかる時間は一定ではありません。クラスターは、クライアントを組織することによって異なるノードを表示します。論理ビューを維持します。インターネット上で同期されていないデータ。分散ドメインにおける一貫性の概念です。

• A違い：

  • ACIDAこれは、トランザクションが分割Atomicity不可能な最小作業単位とみなされ、トランザクション内のすべての操作がすべて正常に送信されるか、すべて失敗してロールバックされることを意味します。

  • CAPA可用性 ( ) を指しますAvailability。これは、クラスター内の一部のノードに障害が発生した後、クラスター全体がクライアントの読み取りおよび書き込み要求に応答できるかどうかを指します。

五、BASE理論

BASEBasically Available(基本的に利用可能)、Soft state(ソフト状態)、Eventually consistent(最終的には整合性がある)の頭字語です。

分散システムでは、CAP理論は指針となる考え方であり、BASE理論はCAP理論のAP拡張であり、CAPシステム内の一貫性と可用性の間のトレードオフの結果です。中心となる考え方は次のとおりです。各アプリケーションは、それぞれのビジネス特性に応じて、システムの最終的な整合性を実現するために適切な方法を採用できます。

• 基本可用性 ( Basically Available): 分散システムに障害が発生した場合、コアが確実に使用できるようにするために、可用性の一部を失うことが許可されることを意味します。

• フレキシブルな状態 ( Soft state）: システムが中間状態を持つことを許可することを指し、中間状態はシステム全体の可用性に影響を与えないと考えられます。たとえば、異なるノード間のレプリカ同期を可能にする遅延は、フレキシブルの具体化です)州。

• 最終整合性 ( Eventually consistent): システム内のすべてのコピーが、一定期間後に最終的に整合性のある状態に到達できることを意味します。したがって、最終整合性の本質は、システムが最終データの整合性を保証する必要があることであり、システム データの強力な一貫性をリアルタイムで保証する必要はありません。

6. トランザクションの一貫性

• 強い一貫性: システム内の特定のデータが正常に更新されると、後続のアクセスで更新された値を確認できるようになります。

• 弱い整合性: システム内の特定のデータが更新された後、その後のアクセスでは更新された値、または変更前の値が取得される可能性があります。

• 最終整合性: システム内の特定のデータが更新され、一定の時間が経過すると、すべてのアクセスが最終的に更新された値になります。

厳格な業務:ACID原則に従い、強い一貫性を保ちます。

柔軟なトランザクション:BASE理論に従い、最終的な整合性を保ちます。

七、セット

Seataこれは、2019 年 1 月に Ant Financial と Alibaba が共同でオープンソース化した分散トランザクション ソリューションです。高性能で使いやすい分散トランザクション サービスを提供することに尽力し、ユーザーにワンストップの分散ソリューションを構築します。

公式 Web サイトのアドレス: http://seata.io/。ドキュメントとポッドキャストで多くの使用方法とソース コード分析が提供されます。

7.1 アーキテクチャ

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

• TC( Transaction Coordinator) - トランザクション コーディネーター: グローバル トランザクションとブランチ トランザクションの状態を維持し、グローバル トランザクションのコミットまたはロールバックを調整します。

• TM( Transaction Manager) - トランザクション マネージャー: グローバル トランザクションのスコープを定義し、グローバル トランザクションを開始し、グローバル トランザクションをコミットまたはロールバックします。

• RM( Resource Manager) - リソース マネージャー: ブランチ トランザクションのリソースを管理し、TC と対話してブランチ トランザクションを登録し、ブランチ トランザクションのステータスを報告し、ブランチ トランザクションをコミットまたはロールバックします。

Seata上記のアーキテクチャに基づいて、4 つの異なる分散トランザクション ソリューションが提供されます。

• XAモード: 強力な整合性フェーズ トランザクション モード。一定の可用性は犠牲になりますが、ビジネスの侵入はありません。

• TCCモード: ビジネス侵入を伴う最終的に整合性のある段階的トランザクション モード

• ATモード: 結果的に一貫性のある段階的トランザクション モード、ビジネス侵入なし、Seata のデフォルト モードでもある

• SAGAモード: ロングトランザクションモード、ビジネス侵入あり

7.2 XAモード

7.2.1 全体の仕組み

Seataによって定義される分散トランザクションのフレームワーク内で、プロトコルのトランザクション リソース (データベース、メッセージ サービスなど)XAのサポートを使用してXA、プロトコルのメカニズムでブランチ トランザクションを管理するトランザクション モード。

RM の最初の段階の作業:

①支店取引をTCに登録する

②ブランチ業務SQLを実行するがサブミットしない

③実行状況をTCに報告

TC の第 2 フェーズの作業:

• TCは各ブランチのトランザクション実行状況を検出

  • a. すべて成功した場合は、すべての RM にトランザクションをコミットするように通知します。
  • b. 障害が発生した場合は、すべての RM にトランザクションをロールバックするように通知します。

RM の第 2 フェーズの作業:

• TC 命令の受信、トランザクションのコミットまたはロールバック

7.2.2 利点と欠点

• XA モードの利点は何ですか?

  • トランザクションの強力な一貫性は ACID 原則を満たします。

  • 一般的に使用されるデータベースがサポートされており、実装が簡単で、コードの侵入がありません。

• XA モードの欠点は何ですか?

  • データベース リソースは第 1 段階でロックされ、第 2 段階の終了後にのみ解放される必要があるため、パフォーマンスが低下します。

  • リレーショナル データベースに依存してトランザクションを実現する

7.3 ATモード

7.3.1 全体の仕組み

ATパターンは、2 フェーズ コミット プロトコル (結果的に整合性のあるフェーズ トランザクション パターン) の進化版です。XAこのモードでのリソースのロック期間が長すぎるという欠点を補います。

フェーズ 1 のRM作業:

• ブランチトランザクションを登録する

• レコードundo-log(データスナップショット)

• 業務を実行しsqlて提出する

• 取引ステータスを報告する

ステージ 2 コミットでのRM作業:

• 削除するundo-logだけです

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

• undo-logアップデート前のデータに戻すと

7.3.2 AT と XA の違い

• XAモードの最初のフェーズでは、トランザクションはコミットされず、リソースはロックされます。ATモードの最初のフェーズでは、リソースはロックされません。

• XAパターンはロールバックのためにデータベース メカニズムに依存し、ATパターンはデータ ロールバックにデータ スナップショットを利用します。

• XAスキーマは強い一貫性を持ち、ATスキーマは最終的に一貫性を持ちます。

7.4 TCCモード

7.4.1 全体の仕組み

全体は2 フェーズ コミットモデルです。グローバル トランザクションは複数のブランチ トランザクションで構成されており、ブランチ トランザクションは2 フェーズ コミットモデルの要件を満たす必要があります。つまり、各ブランチ トランザクションには独自の以下が必要です。

• 最初の段階のTry行動
• 第二段階ConfirmまたはCancel行動

上記のプロセスには、との合計 3 つのメソッドが含まれます。Tryこれら3 つのメソッドは完全にユーザー定義のメソッドであり、自分で実装する必要があります。トランザクション モードと比較して、このモードは基礎となるデータベースのトランザクション サポートに依存しません。ConfirmCancelATTCC

7.4.2 利点と欠点

TCCパターンの各フェーズは何をするのでしょうか?

• Try: リソースの確認と予約

• Confirm: 業務の遂行と提出

• Cancel: 予約リソースの解放

TCC利点は何ですか?

• ダイレクト コミット トランザクションを 1 つのステージで完了し、データベース リソースを解放し、優れたパフォーマンスを実現します。

• ATモデルと比較してスナップショット生成不要、グローバルロック不要でパフォーマンス最強

• データベース トランザクションには依存しませんが、非トランザクション データベースに使用できる補償操作に依存します。

TCCデメリットは何ですか?

• コード侵入があり、try、confirm、cancelインターフェースを手動で記述するのは面倒すぎる

• ソフト状態、トランザクションは最終的に一貫性がある

• sumの失敗を考慮して冪等処理をするConfirm必要があるCancel

7.5 サーガモード

7.5.1 全体の仕組み

SagaこのモードはSeata長期トランザクション ソリューションとして提供されSaga、ビジネス プロセスの各参加者がローカル トランザクションを送信し、特定の参加者が失敗した場合、以前に成功していた参加者が補償されます。報酬サービスは事業開発によって実現されます。

理論的根拠: ヘクターとケネスが論文「Sagas」を発表 (1987)

7.5.2 利点と欠点

• 該当するシーン:
  • 長い業務プロセスと多くの業務プロセス
  • 参加者には、TCC モデルで必要な 3 つのインターフェイスを提供できない他社またはレガシー システム サービスが含まれます。
• アドバンテージ：
  • ローカルトランザクションを 1 フェーズでコミット、ロックフリー、高パフォーマンス
  • イベント駆動型アーキテクチャ、参加者は非同期で実行可能、高スループット
  • 補償サービスは簡単に導入できます
• 欠点:
  • 隔離は保証されていません

8. Seata の 4 つのモードの比較

-	シャー	で	TCC	佐賀
一貫性	強い一貫性	弱い一貫性	弱い一貫性	最終的には一貫性のある
隔離	完全に孤立した	グローバルロック分離に基づく	リソース予約に基づく分離	隔離なし
コードハッキング	なし	なし	はい、記述するインターフェースが 3 つあります	はい、ステートマシンと補償ビジネスを作成します
パフォーマンス	違い	良い	とても良い	とても良い
シーン	一貫性と分離性に対する高度な要件が求められるサービス	リレーショナル データベースに基づくほとんどの分散トランザクション シナリオでは、	高いパフォーマンス要件を伴うトランザクションと非リレーショナル データが関係するトランザクション	ビジネスプロセスが長く、ビジネスプロセスが多く、参加者に他社やレガシーシステムサービスが含まれており、TCCモデルに必要な3つのインターフェースを提供できない