分散トランザクション2PCおよび3PCモデルを徹底的に習得する

[[385682]]

この記事はWeChatの公開アカウント「Source Code Interest Circle」から転載したもので、著者はMa Longtaiです。この記事を転載する場合は、Source Code Interest Circle の公開アカウントにご連絡ください。

ローカルトランザクションは仕事で最もよく使用されますが、単一のプロジェクトをSOAとマイクロサービスに分割すると、分散トランザクションのシナリオが関係します。

この記事では主に分散トランザクションについて説明し、2PC および 3PC アルゴリズムについて詳しく説明します。最後に、分散トランザクションをよりよく理解できるようにデモを使用します。記事のディレクトリ構造は次のとおりです

取引とは何か
分散トランザクションとは何か
DTP モデルと XA 仕様
- DTPモデルとは
- XA 仕様とは何ですか?
2PCコンセンサスアルゴリズム
- 2PC-準備フェーズ
- 2PCコミットフェーズ
- 2PCアルゴリズムの利点と欠点
3PCコンセンサスアルゴリズム
JDBC操作MySQL XAトランザクション
結論

取引とは何か

トランザクションは、データベース操作の最小の作業単位であり、分割できない一連の操作であり、単一の論理的な作業単位として実行される一連の操作です。これらの操作はシステム全体に送信され、すべてが実行されるか、まったく実行されないかのいずれかになります。

トランザクションには、アトミック性、一貫性、独立性、永続性という 4 つの特性があり、これらはトランザクションの ACID 特性と呼ばれます。

トランザクションの ACID プロパティを確保するにはどうすればよいですか?

アトミック性: トランザクション内のSQL文は、UNDOログに基づいて同時に成功するか失敗するかのいずれかになります。
一貫性: システムは正しい状態から別の正しい状態に移行します。これは AID を通じてアプリケーションによって保証されます。それは取引の核となる特徴であると言えます。
分離: ロックとマルチバージョン同時実行制御 (mvcc) に基づいて、トランザクションが同時に実行されるときのデータの可視性を制御します。
耐久性: 送信後、データは正常に保存され、失われることはありません。これは、REDO ログに基づいて実現されます。

この記事では、主に分散トランザクション 2PC と 3PC について紹介します。 redo、undo log、mvcc、lock に関する内容は後ほど詳しく紹介します。

以前は、アプリケーションは単一のプロジェクトだったので、ローカルトランザクションと呼ばれる単一のデータベースを操作していました。ローカルトランザクションの ACID は、通常、私たちが仕事でよく使用する MySQL データベースなどのデータベースレベルでサポートされます。

通常、MySQL クライアントを操作すると、MySQL は暗黙的にトランザクションを自動的にコミットするため、日常業務ではトランザクションの作成、送信、ロールバックなどの操作を手動で記述する必要はありません。ロックや MVCC などの機能をテストする場合は、複数のセッションを作成し、begin、commit、rollback などのコマンドを使用して異なるトランザクション間のデータをテストし、実行結果が目的と一致しているかどうかを確認できます。

通常、プロジェクトコードを開発するときは、Spring のカプセル化されたトランザクションを使用するため、データベーストランザクションのコミットやロールバックなどのメソッドを手動で記述することはありません (一部の場合を除く)。ここでは、ネイティブ JDBC を使用してサンプルコードを記述し、トランザクションを通じて ACID の 4 つの主要な特性を確保する方法を理解できるようにします。

接続conn = ...; // データベース接続を取得する
conn.setAutoCommit( false ); // トランザクションを開始
試す {
   // ...追加、削除、変更、クエリSQLを実行する
   conn.commit (); // トランザクションをコミットする
} キャッチ (例外 e) {
  conn.ロールバック(); // トランザクションのロールバック
ついに
   conn.close (); // 接続を閉じる
}

データベース操作を実行するたびに、トランザクションの作成、コミット、ロールバックなどの繰り返しメソッドを記述する必要があると想像してください。痛くないですか？ Spring はどのようにしてトランザクションの管理を自動的に支援できるのでしょうか? Spring プロジェクトでは、通常、トランザクションを管理するために、プログラムによるトランザクションと宣言的なトランザクションという 2 つの方法を使用します。

インターフェースメソッドに @Transactional アノテーションを追加するか、AOP を使用してアスペクトトランザクションを構成することにより、Spring を使用してプロジェクト内のトランザクションを管理します。実際、これら 2 つのメソッドは似ていますが、@Transactional の方が粒度が細かい点が異なります。原則として、どちらの方法も AOP に依存します。例を見てみましょう。

 @サービス
パブリッククラス TransactionalService {
  @トランザクション
パブリックボイド保存（）{
      //事業運営
  }
 }

TransactionalService は、Spring によってプロキシオブジェクトとして作成され、コンテナーに配置されます。作成されたプロキシオブジェクトは次のクラスと同等です

パブリッククラス TransactionalServiceProxy {
  プライベート TransactionalService トランザクションサービス;
パブリックTransactionalServiceProxy(TransactionalService トランザクションサービス) {
    this.transactionalService = トランザクションサービス;
  } 
   
パブリックボイド保存（）{
      試す {
          // トランザクション操作を開始する
          トランザクションサービスを保存します。
      } キャッチ (例外 e) {
          // 例外が発生した場合はロールバックします
      }
      // トランザクションをコミットする
  }
 }

サンプルコードは簡潔で明確に見えますが、実際のコード生成コードははるかに複雑です。トランザクションマネージャーに関しては、Spring は PlatformTransactionManager インターフェースを提供します。このインターフェースには、次の 2 つの重要な実装クラスが含まれています。

DataSourceTransactionManager: ローカルトランザクションをサポートし、内部的に java.sql.Connection を使用してトランザクションを開始、コミット、ロールバックします。
JtaTransactionManager: 分散トランザクションをサポートするために使用され、JTA仕様を実装し、2フェーズコミットにXAプロトコルを使用します。

これら 2 つの実装クラスを通じて、私たちが通常使用するプログラムトランザクションと宣言型トランザクションは、ローカルトランザクション管理の実装に依存していることがわかります。 Spring は分散トランザクションもサポートします。 JTA 分散トランザクションのサポートについてはオンラインで多くの情報が提供されているため、ここでは詳細には触れません。

分散トランザクションとは何か

私たちは日常のビジネスコードで常にローカルトランザクションを使用しており、理解するのは難しくありません。しかし、サービス指向アーキテクチャ (SOA) とマイクロサービスの普及により、単一のビジネスシステムが複数のシステムに分割されるようになりました。業務システムの変化に対応するため、データベースも業務ごとに分割されています。

例えば、学校管理システムを例にとると、学生サービス、コースサービス、教師サービスなどに分割され、データベースも複数のライブラリに分割されます。このような場合、サーバーにさまざまなサービスをデプロイすると、次のサービス呼び出しが発生する可能性があります。

ServiceA は、ローカルトランザクションを実行するためにデータベースを操作する必要があり、同時にトランザクション呼び出しを開始するために ServiceB と ServiceC を呼び出す必要があります。 3 つのサービスのトランザクションが同時に成功または失敗することを保証するにはどうすればよいでしょうか?ユーザーが開始したトランザクションの ACID 特性をどのように保証するのでしょうか?これは間違いなく分散トランザクションのシナリオです。 3 つのサービスの単一のローカルトランザクションでは、要求全体のトランザクションを保証することはできません。

分散トランザクションのシナリオには多くのソリューションがあります。さまざまな分類から、強力な一貫性ソリューションと最終的な一貫性ソリューションが存在します。ソリューションには、2PC、3PC、TCC、信頼性の高いメッセージングなどが含まれます。

業界で広く使用されているソリューションには、Alibaba の RocketMQ トランザクションメッセージ、Seata XA モード、信頼性の高いメッセージモデルなどがあります。ただし、分散トランザクションは必ず複数のデータベースを直接的または間接的に操作するため、分散トランザクションの使用によってパフォーマンスの問題という新たな課題も生じます。強力な一貫性のある分散トランザクションまたは補償ソリューションの最終的な一貫性を確保するためにパフォーマンスが低下すると、通常のビジネスにとってメリットよりもコストがかかることは間違いありません。

DTP モデルと XA 仕様

X/Open 組織は、分散トランザクションモデル (DTP) と分散トランザクションプロトコル (XA) を定義します。 DTP は次のモデル要素で構成されます。

AP (アプリケーション): トランザクション境界 (つまり、トランザクションの開始と終了の定義) を定義し、トランザクション境界内のリソースを操作するために使用されます。
TM (トランザクションマネージャー): トランザクションの一意の識別子の割り当て、トランザクション実行の進行状況の監視、トランザクションのコミットとロールバックを担当します。
RM（リソースマネージャ）：データベース、ファイルシステムなどのリソースにアクセスするための手段を提供する
CRM (コミュニケーションリソースマネージャー): TM ドメイン内または TM ドメイン間の分散アプリケーション間の通信を制御します。
CP（通信プロトコル）：CRMが提供する分散アプリケーションノード間の基盤となる通信サービスを提供します。

DTP分散トランザクションモデルでは、次の図に示すように、基本コンポーネントにAP、TM、RMSを含める必要があります（CRMとCPがなくても可能です）。

XA仕様

XA 仕様の最も重要な機能は、RM (リソースマネージャー) と TM (トランザクションマネージャー) 間の相互作用インターフェイスを定義することです。 XA仕様は、2PC間の相互作用インターフェースを定義するだけでなく、2PCの最適化も行う。

DTP、XA、2PCの関係を整理する

DTP は分散トランザクションのロールモデルを定義し、グローバルトランザクションの制御にはデータの一貫性を確保するために 2PC プロトコルの使用が必要であることを指定します。

2PC は Two-Phase Commit の略で、分散システムアーキテクチャ内のすべてのノードがトランザクション処理中に原子性と一貫性を保証できるようにするために、コンピュータネットワーク、特にデータベース分野で設計されたアルゴリズムです。同時に、2PC は分散システムデータの一貫性を確保するための一貫性プロトコルとしても考えられています。

XA 仕様は、X/Open 組織によって提案された分散トランザクション処理仕様です。 XA 仕様は、上図の RM と TM 間の相互作用である 2PC (2 フェーズコミットプロトコル) に必要なインターフェイスを定義します。 2PC と XA は最も混同されやすいです。 DTP モデルで定義された TM と RM 間の通信用インターフェース仕様を XA と呼び、X/Open が提案する XA 仕様 (コアは 2PC アルゴリズムに依存) に基づくリレーショナルデータベース (MySQL など) を XA ソリューションと呼ぶことがわかります。

2PCコンセンサスアルゴリズム

アプリケーション (AP) が複数の分散ノードにまたがる必要があるトランザクション操作を開始すると、各分散ノード (RM) はトランザクション操作の結果が成功したか失敗したかを認識しますが、他の分散ノードの操作結果を取得することはできません。トランザクション処理の ACID 特性を確保するには、分散実行ロジックを均一にスケジュールする「コーディネーター」(TM) と呼ばれるコンポーネントを導入する必要があります。

コーディネータは、全体的なトランザクションに参加している分散ノードの動作をスケジュールする責任があり、最終的にこれらの分散ノードがトランザクションをコミットするかロールバックするかを決定します。したがって、この考えに基づいて、2 フェーズコミットと 3 フェーズコミットという 2 つの分散一貫性アルゴリズムプロトコルが派生しました。 2 番目の段階は、準備段階と提出段階を指します。まずは準備段階で何が行われるのか見てみましょう。

2PC-準備フェーズ

2 フェーズコミットの最初のフェーズは「投票フェーズ」とも呼ばれ、各参加者が次のトランザクションコミットステップの実行を続行するかどうかを示すために投票します。

トランザクションの照会: コーディネータは、この分散トランザクションのすべての参加者にトランザクションの内容を送信し、トランザクションのコミット操作を実行できるかどうかを尋ね、各参加者の応答を待ちます。
トランザクションの実行: 参加者はコーディネータからトランザクション要求を受け取り、対応するトランザクションを実行し、その内容をUndoログとRedoログに書き込みます。
応答を返す: 各参加者がトランザクションを実行すると、コーディネータに Yes 応答が返されます。各参加者がトランザクションを正常に実行できなかった場合、コーディネータに No 応答が返されます。

最初のフェーズのすべての参加者が成功応答を返すと、トランザクションコミットステップが開始されます。そうでない場合、分散トランザクションは失敗として返されます。 MySQL データベースを例にとると、最初の段階では、トランザクションマネージャー (TM) が関係するすべてのデータベース (RM) に準備要求を送信します。リクエストを受信すると、データベースはデータの変更とログレコードの処理を実行します。処理が完了すると、トランザクションのステータスは「コミット可能」に変更され、最終的に結果がトランザクションプロセッサに返されます。

2PCコミットフェーズ

コミットフェーズは 2 つのプロセスに分かれています。 1 つは、各参加者がトランザクションコミットプロセスを通常どおり実行し、各参加者が正常に投票したことを示す Yes 応答を返すことです。もう 1 つは、参加者の 1 つが実行に失敗し、応答なしまたはタイムアウトを返すと、分散トランザクションの実行が失敗したことを示すグローバルロールバックがトリガーされることです。

トランザクションコミットを実行する
トランザクションの中断

トランザクションコミットを実行する

コーディネーターがすべての参加者から Yes 応答を受け取った場合、トランザクションコミット操作が実行されます。

トランザクションのコミット: コーディネーターはすべての参加ノードにコミット要求を送信します。コミット要求を受信すると、各参加者はローカルトランザクションをコミットし、コミットが完了したらトランザクション実行サイクル中に占有されたトランザクションリソースを解放します。
トランザクションを完了する: 各参加者がトランザクションの送信を完了すると、コーディネータに Ack 応答を送信します。コーディネータが応答を受信すると、分散トランザクションが完了します。

トランザクションの中断

いずれかのトランザクション参加者ノードがコーディネータに No 応答をフィードバックした場合 (ここでの No 応答は最初の段階を指すことに注意してください)、またはコーディネータが待機タイムアウト後にすべての参加者からフィードバック応答を受信しなかった場合、トランザクション中断プロセスが実行されます。

トランザクションのロールバック: コーディネーターはすべての参加者にロールバック要求を送信します。ロールバック要求を受信した後、参加者は最初のフェーズで書き込まれた UNDO ログを使用してトランザクションのロールバックを実行し、ロールバックトランザクションの完了後に占有されていたリソースを解放します。
トランザクションの中断: トランザクションのロールバックが完了すると、参加者はコーディネータに Ack メッセージを送信します。コーディネータがトランザクション参加者から Ack メッセージを受信すると、トランザクションは中断されます。

2PCの長所と短所

2PC コミットは、トランザクション処理を投票と実行の 2 つの段階に分割します。基本的な考え方は、各トランザクションを try-before-commit 方式で処理することです。 2PC の利点は明らかです。つまり、原理がシンプルで実装が簡単です。シンプルであるということは、多くの側面が完璧ではないことも意味します。ここに3つの主な欠陥があります。
同期ブロッキング: 最初のフェーズでも 2 番目のフェーズでも、すべての参加者リソースとコーディネーターリソースがロックされます。すべてのノードの準備が整った場合にのみ、トランザクションコーディネーターはグローバルコミットを通知し、参加者がローカルトランザクションをコミットした後にのみリソースが解放されます。このプロセスは比較的長く、パフォーマンスに大きな影響を与えます。
単一障害点: コーディネーターに問題がある場合、2 フェーズコミットプロセス全体が機能しなくなります。さらに、第 2 フェーズでコーディネーターが失敗した場合、他の参加者はトランザクションリソースをロックした状態になります。

データの不整合: コーディネーターが第 2 フェーズですべての参加者にコミット要求を送信すると、コミット要求を送信する前にローカルネットワークの異常が発生するか、コーディネーターがクラッシュし、一部の参加者のみがコミット要求を受信することになります。リクエストを受信した参加者はトランザクションをコミットしますが、その結果、データの不整合が発生します。

2PC のシンプルさと利便性により、上記のような同期ブロック、単一点障害、データの不整合などの状況が発生します。そこで、2PCをベースに改良を加え、3フェーズコミット（3PC）を実装しました。

2PC の使用には多くの制限があります。まず、データベースは XA 仕様をサポートする必要があり、パフォーマンスとデータの一貫性は良くありません。したがって、Seata は XA モードをサポートしていますが、メインモードは依然として AT モードです。

3PCコンセンサスアルゴリズム

3 フェーズコミット (3PC) は 2 フェーズコミット (2PC) の改良版であり、次の 2 つの新機能が導入されています。

コーディネータと参加者は両方とも、2PC の同期ブロック問題を解決し、トランザクションリソースの永続的なロックを回避するために、タイムアウトメカニズムを導入します。
2 フェーズプロトコルは 3 フェーズプロトコルに進化します。 2 フェーズコミットプロトコルの最初のフェーズ「準備フェーズ」は 2 つのフェーズに分割され、CanCommit、PreCommit、do Commit の 3 つのフェーズで構成される新しいトランザクション処理プロトコルが形成されます。

3PC の詳細な提出プロセスについてはここでは説明しません。 2PC と比較した 3PC の最大の利点は、参加者のブロック範囲が縮小され、コーディネータの単一障害点の後でも合意に達し続けることができることです。

永続的なリソースブロックの問題はタイムアウトメカニズムによって解決されますが、3PC には依然としてデータの不整合の問題が残ります。参加者が PreCommit メッセージを受信するときに、ネットワークが分割されている場合、コーディネータと参加者は正常に通信できません。この場合、参加者はトランザクションをコミットします。

2PC と 3PC を理解すると、どちらも分散システムにおけるデータの一貫性の問題を完全に解決できないことがわかります。

JDBC操作MySQL XAトランザクション

MySQL は 5.0.3 以降で XA 分散トランザクションをサポートしており、InnoDB ストレージエンジンのみがこれをサポートしています。 MySQL Connector/Jはバージョン5.0.0以降、XAを直接サポートしています。

DTP モデルでは、MySQL は RM リソースマネージャーに属しているため、MySQL は独自の単一のトランザクションブランチのみを実行するため、ここでは MySQL が XA トランザクションをサポートするというステートメントは示しません。 JDBC を使用して、TM を介して複数の RM を制御し、2PC 分散トランザクションを完了する方法を示します。

ここではまず、GAV Maven バージョンを導入する必要性について説明します。これは、上位バージョン 8.x では XA 分散トランザクションのサポートが削除されたためです (おそらく誰も使用しないため)。

 <依存関係>
    <! -- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->  
    <依存関係>
        <グループID>mysql</グループID>
        <artifactId>mysql-コネクタ-java</artifactId>
        <バージョン>5.1.38</バージョン>
    </依存関係>
 </依存関係>

公式アカウントでは読みやすさを確保するため、複数行のコードを IDEA を通じて 1 行に統合しています。 IDEA に貼り付ける必要がある場合は、フォーマットするだけです。

XA プロトコルの基礎は 2PC コンセンサスアルゴリズムであるため、コードを読む際には、上記の記事で説明した DTP モデルと 2PC を参照して、エラーや実行結果を理解およびシミュレートできます。

 com.mysql.jdbc.jdbc2.optional.MysqlXAConnection をインポートします。com.mysql.jdbc.jdbc2.optional.MysqlXid をインポートします。javax.sql.XAConnection をインポートします。javax.トランザクション.xa.XAException; javax をインポートします。トランザクション.xa.XAResource; javax をインポートします。トランザクション.xa.Xid; インポート java.sql.*; 
 
パブリッククラスMysqlXAConnectionTest {
公共 静的void main(String[] args)はSQLExceptionをスローします{
        // true はデバッグ用に XA ステートメントを印刷することを意味します
        ブール値 logXaCommands = true ;
        // リソースマネージャ操作インターフェースインスタンスRM1を取得します
接続conn1 = DriverManager.getConnection( "jdbc:mysql://localhost:3306/test" , "root" , "root" );XAConnection xaConn1 = new MysqlXAConnection((com.mysql.jdbc. Connection ) conn1, logXaCommands);
        // リソースマネージャ操作インターフェースインスタンスRM2を取得します
接続conn2 = DriverManager.getConnection( "jdbc:mysql://localhost:3306/test" , "root" , "root" );XAConnection xaConn2 = new MysqlXAConnection((com.mysql.jdbc. Connection ) conn2, logXaCommands);
        //AP（アプリケーション）はTM（トランザクションマネージャ）に分散トランザクションの実行を要求し、TMはグローバルトランザクションIDを生成します。
        byte[] gtrid = "distributed_transaction_id_1" .getBytes();フォーマットID = 1;
        試す {
            // ============== RM1 と RM2 でそれぞれトランザクション ブランチを実行します ======================
            //TMはRM1のトランザクションブランチIDを生成します
            byte[] bqual1 = "transaction_001" .getBytes();Xid xid1 = new MysqlXid(gtrid, bqual1, formatId);
            //RM1 でトランザクション ブランチを実行する
            rm1.start(xid1, XAResource.TMNOFLAGS);PreparedStatement ps1 = conn1.prepareStatement( "INSERT into user(name) VALUES ('jack')" );ps1.execute ();rm1.end ( xid1 , XAResource.TMSUCCESS);
            //TMはRM2のトランザクションブランチIDを生成します
            byte[] bqual2 = "transaction_002" .getBytes();Xid xid2 = new MysqlXid(gtrid, bqual2, formatId);
            // RM2 でトランザクション ブランチを実行する
            rm2.start(xid2, XAResource.TMNOFLAGS);PreparedStatement ps2 = conn2.prepareStatement( "INSERT into user(name) VALUES ('rose')" );ps2.execute ();rm2.end ( xid2 , XAResource.TMSUCCESS);
            // ===================== 2 フェーズコミット ===================================
            // フェーズ1: すべてのRMにトランザクションブランチをコミットする準備を依頼する
int rm1_prepare = rm1.準備する（xid1）; int rm2_prepare = rm2.準備する（xid2）;
            // フェーズ2: すべてのトランザクションブランチをコミットする
            rm1_prepare == XAResource.XA_OK && rm2_prepare == XAResource.XA_OK の場合 {
                // すべてのトランザクションブランチが正常に準備されたので、すべてのトランザクションブランチをコミットします
                rm1。コミット(xid1, false );rm2。コミット(xid2, false );
            }それ以外{
                // トランザクションブランチが失敗した場合はロールバックします
                rm1.rollback (xid1);rm1.rollback ( xid2);
            }
        } (XAException e) をキャッチします { e.printStackTrace(); } }}

結論

この記事では、ローカルトランザクションの 4 つの主要な特性を確保する方法、分散トランザクションの出力背景、および 2PC と 3PC が分散状況でデータの一貫性を解決できない理由について、図とテキストを使用して説明します。最後に、JDBC を介した 2PC の実行プロセスを示します。これを読めば、分散トランザクションに対する印象が深まると同時に、DTP、XA、2PC などのわかりにくい概念も明確に理解できるようになると思います。

これは、「分散トランザクション」コラムの第 1 章の冒頭です。今後は、メッセージミドルウェア、信頼性の高いメッセージングモデル、Seata XA モデルを通じて分散トランザクションを完了することに関する記事を完成させ、さまざまな実装方法の長所と短所をまとめ、適切なシナリオに合わせてさまざまな分散トランザクションソリューションを選択する予定です。

著者は、学習するための最良の方法は実践することだと信じています。分散トランザクションを経験したことがない場合は、作成中のプロジェクトを通じて分散トランザクションのビジネスシナリオをシミュレートできます。これにより、印象が深まり、分散トランザクションソリューションに関連する設計のアイデアをより深く理解できるようになります。

<<: 分散クラウドコンピューティングの利点と革新的な実践

>>: 7つのオプション！ Redis 分散ロックの正しい使用法について議論する