「分散トランザクション」を完了するための記事

01分散トランザクションが必要な理由

過去10年間のインターネットの急速な発展により、多くのWebサイトにアクセスする機会が増えています。集中環境では、ビジネスのニーズを満たすことができなくなりました。データは、ビジネスユニットに従ってのみ分割できます(垂直分割と水平分割を含む)。 )、そして初期の集中型変換からサービス指向アーキテクチャの分散アプリケーション環境まで、ビジネスを1つの単位としてサービスを提供します。

典型的な例を挙げると、アリババの淘宝網のWebサイトのトラフィックの増加に伴い、商品、注文、ユーザー、ショップなどのビジネスユニットに応じてデータベースを分割し、ビジネスユニットに応じたサービスインターフェイスを提供するだけです。

 

現時点では、製品の購入後の控除などの単純なビジネス機能を完了するために、ユーザーの注文、製品の在庫、支払いなどの複数のデータベースを含む複数のサービスにまたがる必要があり、これらの操作は同じトランザクションである必要があります。最後に、これには分散トランザクションが含まれます。

基本的に、分散トランザクションは、異なるリソースサーバー間でデータの一貫性を確保するためのものです。

02分散コンセンサス理論

カリフォルニア大学バークレー校の初代教授であるEric Brewerは、分散システム特性のCAP理論を提案しました。

1. CAP理論の不可能な三角形

 

一貫性

可用性(可用性)

パーティション許容差

分散システムでは、一貫性、可用性、およびパーティション許容度を同時に満たす3つの要件はありません。

1文の要約:一貫性、可用性、およびパーティションのフォールトトレランスは、分散トランザクションでは実現できません。

ほとんどのシナリオでは、システムの高可用性と引き換えに強い整合性を犠牲にする必要があり、システムは多くの場合、最終的な整合性を保証するだけで十分です。

これは、後で開発されるBASE理論の基礎でもあります。

2.BASE理論

 

基本的に利用可能

ソフト状態

結果的に一貫した(結果的に一貫した)3つのフレーズの省略形。

BASEは、CAPの一貫性と可用性のバランスの結果です。これは、大規模インターネットシステムの分散実践の結論から導き出されます。CAPの定理に基づいて徐々に進化します。その中核となる考え方は、強力な一貫性が達成できなくても(強い一貫性)ただし、各アプリケーションは適切な方法を採用して、システムに独自のビジネス特性に従って最終的な一貫性を実現できます。

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

1. XAプロトコル2PCに基づく2フェーズコミットプロトコル(2フェーズコミットプロトコル)

XAは分散トランザクションプロトコルです。XAは、トランザクションマネージャーとローカルリソースマネージャーの2つの部分に大別されます。ローカルリソースマネージャーはデータベースによって実装されることが多く、トランザクションマネージャーはさまざまなローカルリソースの管理を担当するグローバルスケジューラです。コミットとロールバック。

 

大まかなプロセス:

最初の段階は投票段階で、すべての参加者がトランザクションの成功に関するフィードバックをコーディネーターに送信します。

2番目のステージは実行ステージです。コーディネーターは、すべての参加者からのフィードバックに基づいてすべての参加者に通知し、一貫した方法ですべてのブランチをコミットまたはロールバックします。

長所と短所

データの強力な一貫性を確保し、実装コストが低いことを確認してください。主要な主流データベースに独自の実装があり、単一障害点、パフォーマンス、およびデータベース間の問題があります。

2.トランザクション補正TCCモード

TCCソリューションは、実際には2フェーズサブミッションの改良版であり、ビジネスロジック全体の各ブランチは、試行、確認、キャンセルの3つの操作に明示的に分割されます。

試行部分はビジネスの準備を完了し、確認部分はビジネスの送信を完了し、キャンセル部分はトランザクションのロールバックを完了します。次の図に基本原理を示します。

 

長所と短所

これは、コードに侵入し、ロックの競合を減らし、スループットを向上させますが、実装がそれほど簡単でない場合もあります。

場合

Ant FinancialのDTS(準備、コミット、ロールバック)

3.メッセージキューの結果整合性スキーム

非同期デカップリング、サードパーティのミドルウェア

 

場合

RocketMQ、RabbitMQなどを実装できます。RocketMQには特別なトランザクションメッセージもあり、Kafkaの新しいバージョンにもそれがあります。

つまり、分散システムでのトランザクションはCAPのトレードオフであり、実際のアプリケーションでは、ビジネス要件、開発者の条件、および使用されるさまざまなフレームワークに従って調整が行われます。

おすすめ

転載: blog.csdn.net/JavaJIAMIN/article/details/108540399