5 つの主要な分散トランザクションについてどれくらい知っていますか?

[[396086]]

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

1. はじめに

トランザクション: 一般的に、実行する必要があること、または実行されたことを指し、トランザクションの開始 (トランザクションの開始) からトランザクションの終了 (トランザクションの終了) までの間に実行されるすべての操作で構成されます。

簡単に言えば、すべてが実行されるか、すべてが失敗するかのどちらかです。

分散トランザクションは、分散システムで実行され、複数の異なるマシン上のトランザクションで構成されるトランザクションです。上記のように、分散システム内のすべてのトランザクションが実行された場合にのみ成功し、そうでない場合は失敗します。

トランザクションACIDの基本特性:

原子性: トランザクションは分割できない作業単位です。トランザクションに含まれるすべての操作は、実行されるか、実行されないかのいずれかになります。
一貫性: トランザクションが実行される前と実行後のデータの整合性を指します。
分離: トランザクションの実行は他のトランザクションによって妨害されることはありません。つまり、トランザクション内で使用される操作とデータは他の同時トランザクションから分離されており、同時に実行されるトランザクションは互いに干渉できません。
永続性: 永続性とも呼ばれ、トランザクションがコミットされると、データベース内のデータに加えられた変更は永続的に保存されます。

2. 分散トランザクションの目標と実際の適用シナリオ

分散トランザクションの目的は、複数の独立したトランザクションの一貫性の問題を解決することです。

たとえば、複数のマイクロサービスにまたがる注文システムという機能があります。各マイクロサービスはライブラリ内にないため、データベーストランザクションを使用してトランザクションを保証することはできません。この場合、分散トランザクションを使用できます。

例: ショッピングモールプロジェクトでは、ユーザーが注文に対して支払いを行います。支払いシステムでは、支払いテーブルが更新されます。別の注文システムでは、注文データベース内の注文のステータスが支払済みになります。注文テーブルと支払いテーブルは異なるデータベースにあるため、2 つのデータベース間のトランザクションをどのように保証できますか?

支払操作：支払残高の変更、注文ステータスの変更

3. 分散トランザクションソリューション

2 フェーズコミットプロトコル (2PC)
3 フェーズコミットプロトコル (3PC)
補償取引（TCC）
メッセージミドルウェアの実装
シータフレーム

4. 2フェーズコミットプロトコル（2PC）

XAプロトコルに基づいて、強力な一貫性を採用し、ACIDに準拠します。

2PC: (2 フェーズコミットプロトコル) は、XA/JTA 仕様に基づいています。

4.1 ゼオ

XA は、X/Open 組織によって提案された分散トランザクションアーキテクチャ (またはプロトコル) です。 XA アーキテクチャは主に、(グローバル) トランザクションマネージャーと (ローカル) リソースマネージャー間のインターフェイスを定義します。

XA インターフェイスは、トランザクションマネージャーと 1 つ以上のリソースマネージャー間の通信ブリッジを形成する双方向システムインターフェイスです。つまり、XA ベースのトランザクションでは、複数のデータベースにアクセスするシステムや、データベースとメッセージングミドルウェアなどのリソースの両方にアクセスするシステムなど、複数のリソースのトランザクション管理を実行できます。このようにして、コミットされたすべてのトランザクションまたはキャンセルされたすべてのトランザクションを複数のデータベースとメッセージミドルウェアに直接実装できます。 XA 仕様は Java 仕様ではなく、一般的な仕様です。

4.2 シリアル

JTA (Java Transaction API) は、XA プロトコルの JAVA 実装である J2EE のプログラミングインターフェイス仕様です。主に以下を定義します。

トランザクションマネージャーインターフェイス javax.transaction.TransactionManager は、トランザクションの開始、コミット、取り消しなどの操作を定義します。 XA 仕様に準拠したリソース定義インターフェース javax.transaction.xa.XAResource。リソースが JTA トランザクションをサポートする場合、XAResource インターフェイスと、インターフェイスによって定義された 2 フェーズコミット関連のインターフェイスを実装する必要があります。

4.3 フローチャート

4.4 提出プロセス

1. 要求フェーズ (コミット要求フェーズ、投票フェーズとも呼ばれる、手順 (1 ～ 5)) 要求フェーズでは、コーディネーターはトランザクション参加者にトランザクションをコミットまたはキャンセルする準備をするように通知し、その後投票プロセスに入ります。投票プロセス中に、参加者はコーディネーターに決定を通知します。同意 (トランザクション参加者のローカルジョブ実行が成功) またはキャンセル (ローカルジョブ実行が失敗)。

2. コミットフェーズ、手順 (6 ～ 7) このフェーズでは、コーディネータは最初のフェーズの投票結果に基づいてコミットするかキャンセルするかを決定します。すべての参加者がトランザクションをコミットすることに同意した場合にのみ、コーディネーターはすべての参加者にトランザクションをコミットするように通知します。それ以外の場合は、コーディネーターはすべての参加者にトランザクションをキャンセルするように通知します。参加者はコーディネーターからのメッセージを受信した後、対応する操作を実行します。

4.5 デメリット

単一障害点: トランザクションの開始、送信、キャンセルはすべてコーディネータによって管理されます。コーディネーターがダウンしたら、すべてが台無しになります。
同期ブロッキングのデメリット: 上記の紹介と例から、参加システムがボスの実際の送信またはキャンセルトランザクション指示を受信しない場合、現在のリソースがロックされ、実際にはトランザクション関連の操作が実行されないことがわかります。そのため、分散システム環境全体がブロックされます。
データの不整合のデメリット: ボスコーディネーターが実際のトランザクション送信を弟に送信すると、ネットワーク障害により一部のシステムが実際の指示を受信できず、一部の送信が表示され、一部の送信は表示されません。したがって、データの不整合が発生します。

4.6 解決できない問題

コーディネータがミスを犯し、参加者もミスを犯した場合、2 フェーズプロセスではトランザクション実行の整合性を保証できません。コミットメッセージを送信した後にコーディネータがクラッシュし、このメッセージを受信する唯一の参加者も同時にクラッシュするとします。そうすると、新しいコーディネーターがいても、このトランザクションのステータスは不確実であり、トランザクションがコミットされたかどうかは誰にもわかりません。それを知っていた人々は沈黙させられた。

5. 3フェーズコミットプロトコル（3PC）

強力な一貫性を採用し、ACID に準拠します。第 2 フェーズでは、タイムアウトと事前送信のメカニズムが追加されます。 3つの主要なフェーズ、canCommit、preCommit、doCommitがあります。

5.1 フローチャート

5.2 プロセス

1. CanCommit フェーズ: 3PC の CanCommit フェーズは、実際には 2PC の準備フェーズと非常によく似ています。コーディネーターは参加者にコミット要求を送信し、参加者はコミットできる場合は Yes 応答を返し、そうでない場合は No 応答を返します。

2. PreCommit フェーズ: コーディネータは、コホートの応答に基づいて、トランザクションの PreCommit 操作を続行するかどうかを決定します。

応答に応じて 2 つの可能性があります。 A. コーディネーターがすべてのコホートから Yes 応答を受け取った場合、トランザクションを事前実行し、事前コミット要求を送信します。コーディネーターはコホートに PreCommit リクエストを送信し、準備フェーズに入ります。トランザクションの事前コミット。 PreCommit 要求を受信すると、コホートはトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクションログに記録します。フィードバックに応答します。コホートがトランザクション操作を正常に実行すると、ACK 応答を返し、最終命令の待機を開始します。

B. いずれかのコホートがコーディネータに No 応答を送信した場合、またはコーディネータが待機タイムアウト後にコホートから応答を受信しなかった場合、割り込み要求を送信してトランザクションが中断されます。コーディネーターはすべてのコホートに中止要求を送信します。トランザクションを中断します。コホートがコーディネータから中止要求を受信した後 (またはタイムアウト後もコホート要求が受信されない場合)、トランザクションは中断されます。

3. DoCommit フェーズ: このフェーズは実際のトランザクションをコミットするために使用されます。これは次の 2 つの状況に分けられます。

commitAを実行します。コミットリクエストを送信します。コーディネーターは、コホートから送信された ACK 応答を受信すると、コミット前状態からコミット状態に移行します。そして、すべてのコホートに doCommit リクエストを送信します。 B.トランザクションのコミット。 doCommit リクエストを受信すると、Cohort は正式なトランザクションコミットを実行します。トランザクションのコミットが完了したら、すべてのトランザクションリソースを解放します。 C. フィードバックに応答します。トランザクションがコミットされると、ACK 応答がコーディネーターに送信されます。 D. 取引を完了します。コーディネーターがすべてのコホートから ACK 応答を受信すると、トランザクションが完了します。

割り込みトランザクションコーディネータが参加者から送信された ACK 応答を受信しない場合、割り込みトランザクションが実行されます。

A. 割り込み要求を送信します。コーディネーターはすべての参加者に中止要求を送信します。 B. トランザクションのロールバック。中止要求を受信した後、参加者はフェーズ 2 で記録された元に戻す情報を使用してトランザクションのロールバック操作を実行し、ロールバックが完了したらすべてのトランザクションリソースを解放します。 C. フィードバック結果参加者がトランザクションのロールバックを完了すると、コーディネータに ACK メッセージを送信します。 D. トランザクションの中断コーディネータは参加者からフィードバックされた ACK メッセージを受信すると、トランザクションの中断を実行します。

5.3 デメリット

コーディネータが PreCommit に入った後に中止要求を送信した場合、1 つのコホートのみが中止操作を受信して実行し、システムステータスに不明な他のコホートが 3PC に基づいてコミットを続行することを選択すると、システムステータスが不整合になります。

5.4 2PCと3PCの違い

質問を追加すると成功の可能性が高まります。

タイムアウトメカニズムは、コーディネーターとコホートの両方に設定されます (2PC では、タイムアウトメカニズムがあるのはコーディネーターのみで、つまり、一定時間内にコホートからメッセージが受信されない場合は、デフォルトで失敗します)。コーディネータが失敗し、参加者がタイムアウトを待機する場合、トランザクションはデフォルトでコミットされます。少し進歩しました。

参加者が異常であり、コーディネーターも異常である場合、他の参加者は強制的に服従させられます。

事前コミットフェーズは 2PC の準備フェーズとコミットフェーズの間に挿入されるため、3PC には CanCommit、PreCommit、DoCommit の 3 つのフェーズがあります。 PreCommit は、最終コミットフェーズの前に、参加しているすべてのノードの状態が一貫していることを保証するバッファーです。

6. メッセージベースの最終的な一貫性

最終的な一貫性を採用し、BASE 理論に従います。

BASE: 正式名称は、「Basically Available (基本的に利用可能)」、「Soft state (ソフト状態)」、「Eventually Consistent (最終的に一貫性がある)」という 3 つのフレーズの略称です。これはeBayの建築家によって提案されました。

基本的に利用可能: 分散システム環境では、メインプロセスに影響しない一部の機能の利用不可を犠牲にしてダウングレードし、コアサービスの通常の可用性を確保することが許可されます。

ソフト状態: トランザクションにおいて、システムに影響を与えることなく、システムが中間状態を持つことを許可することを意味します。データベースのマスター・スレーブ・レプリケーションを例に挙げます。レプリケーション中に遅延が発生することは完全に許容されます。

最終的に一貫性がある: データベースのマスタースレーブレプリケーションを例にとると、マスタースレーブレプリケーションにはわずかな遅延がありますが、最終的にはすぐにデータの一貫性が保たれます。

分散トランザクションは問題を 100% 解決することはできませんが、成功の確率を高めることしかできません。 2 つのステージ間の時間はミリ秒単位です。解決策: 時間指定のタスク補正。プログラムまたはスクリプトの補償。人間の介入。

7. TCC

ソリューション: TCC (Try、Confirm、Cancel)、2 段階の補償ソリューション。

名前の通り、トランザクションを実装するには、リソースの事前占有、実際の操作リソースの確認とコミット、占有のキャンセル = ロールバックの 3 つの API を定義する必要があります。

後者の 2 つのステップが実行の途中で失敗した場合は、ログに記録し、補正を行って、人間のスタッフに通知します。

2PC: リソースレベルでの分散トランザクションであり、常にリソースロックを保持します。

データベースが 12 個以上ある場合、一度に多数のデータベースをロックすると、リソースが極度に浪費されることになります。スループットが低下しました。

TCC: ビジネスレベルでの分散トランザクションは最終的に一貫性があり、常にロックを保持するわけではありません。ロックの粒度が削減され、データベースに対する各操作の後にロックが解除されます。

それはすべて相対的です。1 日にリクエストが 1 件しかない場合は、2PC の方が TCC よりもパフォーマンスが優れています。 tcc には複数のインターフェース呼び出しがあるためです。現時点では、2PC は 1 回の呼び出しだけなので、リソースを占有することを恐れません。 TCC は、同時実行性の高いシナリオで大きな利点があります。

8. メッセージミドルウェアの実装

メッセージキューの柔軟なトランザクションフローチャート:

1. 支払いテーブルを操作し、状態を「新規」にしてイベントテーブルにデータを挿入し、データベースに格納します。これらの操作 (1、2、3) はすべて 1 つのデータベース内にあるため、1 つのトランザクションに含まれます。

2. スケジュールされたタスクはイベントテーブルを読み取り、キューに送信します。送信が成功すると、イベントテーブル new の状態が (公開済み) に変更され、イベントテーブルが監視され、イベントテーブルにデータが挿入されます。

3. スケジュールされたタスクが公開イベントテーブルを読み取るかどうかを確認します。公開されたイベントテーブルの場合は、注文テーブルを更新し、イベントテーブルを処理済みに更新します。これにより、大きなトランザクションが複数の小さなトランザクションに分割されます。

テーブルデザイン:

作成する テーブル`t_order_event` (
  `id` int (16)ではない  NULL 、
  `order_type` varchar (32)デフォルト  NULL COMMENT 'イベントタイプ（支払いテーブルの支払い完了、注文テーブルの変更ステータス）' 、
  `process` varchar (32)文字  utf8mb4をutf8mb4_0900_ai_ciのデフォルトにセットする  NULL COMMENT 'イベントリンク（新規、公開済み、処理済み）' 、
  `content` varchar (255)デフォルト  NULL COMMENT 'イベントコンテンツ、イベント発生時に渡す必要のあるデータを保存します' 、
  `create_time` 日時デフォルト  NULL  の上 アップデート  CURRENT_TIMESTAMP 、
  `update_time` 日時デフォルト  NULL  の上 アップデート  CURRENT_TIMESTAMP 、
主要な キー(`id`)
 ) エンジン=InnoDBデフォルト文字セット=utf8mb4照合=utf8mb4_0900_ai_ci;

9. Seataフレームワーク

Seata は、高性能で使いやすい分散トランザクションサービスを提供することを目的としたオープンソースの分散トランザクションソリューションです。 Seata は、ユーザーに AT、TCC、SAGA、XA トランザクションモードを提供し、ユーザー向けのワンストップ分散ソリューションを作成します。

公式ウェブサイト API (強く推奨): https://seata.io/zh-cn/docs/overview/what-is-seata.html

Seata ダウンロードアドレス: https://seata.io/zh-cn/blog/download.html

フローチャート:

手順:

1. seataサーバーをダウンロードする

https://seata.io/zh-cn/blog/download.html

2. file.confを変更する

サービス {
  #トランザクションサービスグループマッピング
  # 変更、オプション、my_test_tx_group に任意の名前を付けるだけです。
  vgroup_mapping.my_test_tx_group = "デフォルト"  
  # registry.type=fileの場合にのみサポートされます。複数のアドレスを設定しないでください。
  # このサービスのアドレス
デフォルト.grouplist = "127.0.0.1:8091"  
  #シートを無効にする
  グローバルトランザクションを無効にする = false  
 } 
 
店 {
  ## 保存モード: ファイル、DB
  ＃ 改訂
  モード = "db"   
 
  ## ファイルストアプロパティ
  ファイル {
    ##保存場所のディレクトリ
    dir = "セッションストア"  
  } 
 
  ##データベースストアプロパティ
  #db情報の変更
  デシベル{
    ## DruidDataSource(druid)/BasicDataSource(dbcp)などのjavax.sql.DataSourceの実装。 
   
    データソース = "ドルイド"  
    ## mysql/oracle/h2/oceanbase など
    dbタイプ = "mysql"  
    ドライバークラス名= "com.mysql.cj.jdbc.Driver"  
    url = "jdbc:mysql://127.0.0.1:3306/seata-server?useUnicode=true&useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai"  
ユーザー= "root"  
パスワード= "root"  
  }
 }

3. registry.confを変更する

レジストリ {
  # ファイル、nacos、eureka、redis、zk、consul、etcd3、sofa
  ＃改訂
  タイプ = "ユーレカ"   
 
  ナコス
    サーバーアドレス = "localhost"  
    名前空間 = ""  
    クラスター = "デフォルト"  
  }
  ＃改訂
  ユーレカ
    サービス URL = "http://localhost:8761/eureka"  
    アプリケーション = "デフォルト"  
    重み = "1"  
  }
  レディス{
    サーバーアドレス = "localhost:6379"  
    デシベル = "0"  
  }
  ずっ
    クラスター = "デフォルト"  
    サーバーアドレス = "127.0.0.1:2181"  
    セッションタイムアウト = 6000
接続.タイムアウト = 2000
  }
  領事 {
    クラスター = "デフォルト"  
    サーバーアドレス = "127.0.0.1:8500"  
  }
  etcd3 {
    クラスター = "デフォルト"  
    サーバーアドレス = "http://localhost:2379"  
  }
  ソファー
    サーバーアドレス = "127.0.0.1:9603"  
    アプリケーション = "デフォルト"  
    リージョン = "DEFAULT_ZONE"  
    データセンター = "DefaultDataCenter"  
    クラスター = "デフォルト"  
グループ= "SEATA_GROUP"  
    アドレス待機時間 = "3000"  
  }
  ファイル {
名前= "file.conf"  
  }
 } 
 
設定{
  # ファイル、nacos、apollo、zk、consul、etcd3
  タイプ = "ファイル"   
 
  ナコス
    サーバーアドレス = "localhost"  
    名前空間 = ""  
  }
  領事 {
    サーバーアドレス = "127.0.0.1:8500"  
  }
  アポロ
    app.id = "seata-server"  
    apollo.meta = "http://192.168.1.204:8801"  
  }
  ずっ
    サーバーアドレス = "127.0.0.1:2181"  
    セッションタイムアウト = 6000
接続.タイムアウト = 2000
  }
  etcd3 {
    サーバーアドレス = "http://localhost:2379"  
  }
  ファイル {
名前= "file.conf"  
  }
 }

4. データベースを作成し、テーブルを作成する

ブランチトランザクションテーブル: branchtableグローバルトランザクションテーブル: globaltableグローバルロック: lock_table

注: 表の構造は間違ってはいけない

5. ロールバック用に各ライブラリにundo_logを追加する

作成する テーブル`undo_log` (
  `id`ビッグイント(20) NOT   NULL AUTO_INCREMENT、
  `branch_id` bigint (20) ではない  NULL 、
  `xid` varchar (100)文字  UT8をセットしてUTF8_general_ciを照合しない  NULL 、
  `context` varchar (128)文字  UT8をセットしてUTF8_general_ciを照合しない  NULL 、
  `rollback_info` longblob ではない  NULL 、
  `log_status` int (11)ではない  NULL 、
  `log_created` 日時NOT   NULL 、
  `log_modified` 日時NOT   NULL 、
  `ext` varchar (100)文字  UT8照合UTF8_general_ciデフォルトを設定  NULL 、
主要な  KEY (`id`) BTREEの使用、
個性的 キー`ux_undo_log` (`xid`,`branch_id`) BTREE の使用
) ENGINE=InnoDBデフォルトCHARSET=utf8 ROW_FORMAT= DYNAMIC ;