分散トランザクションのシナリオとソリューションを徹底的に理解するのに役立つ 12 枚の写真

[[346590]]

著者は、正確にスケジュールされたタスクと遅延キュー処理機能を備えた、高同時実行シナリオ向けのシンプルで安定したスケーラブルな遅延メッセージキューフレームワークを個人的に開発しました。半年以上前にオープンソース化されて以来、10 社を超える中小企業に正確でタイムリーなスケジューリングソリューションを提供することに成功し、実稼働環境でのテストにも耐えてきました。より多くの人々の利益のために、オープンソースフレームワークのアドレスが提供されるようになりました: https://github.com/sunshinelyz/mykit-delay

PS: ソースコードにスターを付けていただくことも歓迎します。また、素晴らしいコードを PR することもできます。

序文

この記事を書いたきっかけは、私と親しい友人が大手インターネット企業に面接に行ったことです。インタビュアーは分散トランザクションについて質問しました。残念ながら、彼は分散トランザクションについて深い理解を持っておらず、面接の結果は非常に残念なものとなりました。しかし、この友人はまだかなり楽観的で、[分散トランザクション]に関する一連の記事を書くように依頼しました。分散トランザクションに関する私の欠点を改善したい場合は、[分散トランザクション]に関する特別なトピックを作成します。特別トピックの内容は、原則、フレームワークのソースコード、エンタープライズレベルの実装をカバーする予定です。この記事は、このトピック全体の始まりとみなすことができます。それが友人たちに大きな助けとなることを願っています。

地方問題

ローカルトランザクションプロセス

分散トランザクションを紹介する前に、ローカルトランザクションについて見てみましょう。まずは写真を見てみましょう。

上の図から、ローカルトランザクションはリソースマネージャー (DBMS、データベース管理システムなど) によってローカルに管理されていることがわかります。

ローカル取引のメリットとデメリット

地方の問題にはそれに応じた長所と短所があります。

アドバンテージ：

厳密な ACID プロパティをサポートします。
信頼性が高く、効率的なトランザクション実装 (ローカル操作のみ)。
トランザクションはRM（リソースマネージャー）でのみ操作できます。
プログラミングモデルはシンプルです。

欠点:

分散トランザクション処理機能の欠如。
データ分離の最小単位は RM (リソースマネージャー) によって決定され、開発者はデータ分離の最小単位を決定することはできません。例: データベース内のレコードなど。

ACIDプロパティ

トランザクションについて話すときは、トランザクションの ACID プロパティについて言及する必要があります。

A (アトミック): 原子性。トランザクションを構成するすべての操作は、完了まで実行されるか、まったく実行されないかのいずれかになります。一部の操作が成功し、他の操作が失敗することはあり得ません。
C (一貫性): 一貫性。トランザクションの実行前と実行後にデータベースの一貫性制約に違反しません。例: 張三は李思に100元を送金します。転送前後のデータの正しい状態を一貫性と呼びます。張三が100元を送金しても李思の口座残高が100元増加しない場合は、データエラーであり、一貫性が達成されません。
I (Isolation): 隔離。データベース内のトランザクションは通常、同時実行されます。分離とは、2 つの同時トランザクションの実行が互いに干渉せず、1 つのトランザクションが他のトランザクションの中間ステータスを確認できないことを意味します。トランザクション分離レベルを構成することで、ダーティリードや繰り返し読み取りなどの問題を回避できます。
D (耐久性): トランザクションが完了すると、トランザクションによってデータに加えられた変更はデータベースに保持され、ロールバックされません。

分散トランザクション

ビジネスの急速な発展に伴い、Web サイトシステムはモノリシックアーキテクチャから分散型マイクロサービスアーキテクチャへと徐々に進化する傾向があり、データベースは単一マシンデータベースアーキテクチャから分散型データベースアーキテクチャへと変化する傾向があります。この時点で、大規模なアプリケーションシステムを、独立して展開できる複数のアプリケーションサービスに分割し、トランザクション操作を完了するにはサービス間のリモートコラボレーションが必要になります。

最初のシステムのモノリシックアーキテクチャを表すには、次の図を使用します。

上図では、同じプロジェクト内の異なるモジュールを異なるパッケージに整理して管理していますが、すべてのプログラムコードは同じプロジェクト内に配置されています。

その後、ビジネスの発展に伴い、分散型のマイクロサービスアーキテクチャに拡張しました。この時点で、以下に示すように、大規模なプロジェクトを、それぞれ独自のデータベースを持ち、独立してデプロイできる小さなマイクロサービスに分割します。

たとえば、私たちのプログラムでは、ニーズを満たすために、同じトランザクション内で次のようなコードを実行することがよくあります。

 @Transactional(ロールバックFor = Exception.class)
パブリックボイドsubmitOrder() {
    orderDao.update (); // 注文情報を更新する
    accountService.update(); //資本勘定の金額を変更する
    pointService.update (); // ポイントを変更する
    accountingService.insert(); //トランザクションフローを挿入する
    マーチャント通知サービス。通知(); // 支払い結果を通知する
}

上記のコードのビジネスでは、submitOrder() メソッドに @Transactional アノテーションのみを追加します。これにより、分散シナリオにおける分散トランザクションの問題を回避できますか?明らかにそうではありません。

上記コードに対応する情報、すなわち注文情報、資金口座情報、ポイント情報、取引フローおよびその他の情報がそれぞれ異なるデータに保存されている場合、支払いが完了した後、通知された対象システムのデータも異なるデータベースに保存されます。ここで、分散トランザクションの問題が発生します。

分散トランザクションのシナリオ

クロスJVMプロセス

モノリシックプロジェクトを分散型のマイクロサービスプロジェクトに分割すると、各サービスが連携して、リモート REST または RPC 呼び出しを通じてビジネス操作を完了します。典型的なシナリオは、ショッピングモールシステム内の注文マイクロサービスと在庫マイクロサービスです。ユーザーが注文を行うと、注文マイクロサービスが注文マイクロサービスにアクセスします。注文マイクロサービスが注文レコードを生成すると、在庫マイクロサービスを呼び出して在庫を差し引きます。各マイクロサービスは異なる JVM プロセスにデプロイされます。このとき、JVM 間プロセスによって分散トランザクションの問題が発生してしまいます。

データベースインスタンス全体

単一のシステムが複数のデータベースインスタンスにアクセスする場合、つまりデータソース間にアクセスする場合、分散トランザクションが生成されます。たとえば、システム内の注文データベースとトランザクションデータベースは、異なるデータベースインスタンスに配置されます。ユーザーが払い戻しを開始すると、ユーザーの注文データベースと取引データベースが同時に操作されます。返金操作はトランザクションデータベースで実行され、注文データベースで注文ステータスが返金済みに変更されます。データは異なるデータベースインスタンスに分散されるため、データベース内のデータを操作するには異なるデータベース接続セッションが必要です。このとき、分散トランザクションが生成されます。

複数のサービス、単一のデータベース

複数のマイクロサービスが同じデータベースにアクセスします。たとえば、注文マイクロサービスと在庫マイクロサービスが同じデータベースにアクセスすると、分散トランザクションも生成されます。その理由は、複数のマイクロサービスが同じデータベースにアクセスすると、基本的には異なるデータベースセッションを通じてデータベースを操作することになり、分散トランザクションが生成されるからです。

注: データベースインスタンス間のシナリオとマルチサービスの単一データベースシナリオはどちらも、基本的には、データベース内のデータを操作するために異なるデータベースセッションが生成され、分散トランザクションが生成されるためです。これら 2 つのシナリオは見落とされがちです。

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

分散トランザクションが発生するシナリオがわかったので、分散トランザクションの具体的なソリューションについて説明しましょう。

2PCソリューション

2PC (2 フェーズコミットプロトコル) は、トランザクションプロセス全体を準備フェーズとコミットフェーズの 2 つのフェーズに分割します。 2 は 2 つのフェーズ、P は準備フェーズ、C はコミットフェーズを表します。

ここでは、MySQL データベースを例として使用します。 MySQL データベースは 2 フェーズコミットプロトコルをサポートしており、成功と失敗の 2 つの状況に分けられます。

成功

失敗

具体的なプロセスは以下のとおりです。

準備フェーズ: トランザクションマネージャーは各参加者に準備メッセージを送信します。各データベース参加者はトランザクションをローカルで実行し、ローカルの Undo/Redo ログを書き込みます。現時点ではトランザクションはコミットされていません。 (UNDO ログは変更前のデータを記録し、データベースのロールバックに使用されます。一方、REDO ログは変更後のデータを記録し、トランザクションをコミットした後にデータファイルを書き込むために使用されます)

コミットフェーズ: トランザクションマネージャーが参加者から実行失敗またはタイムアウトメッセージを受信すると、各参加者にロールバックメッセージを直接送信します。それ以外の場合はコミットメッセージを送信します。参加者は、トランザクションマネージャーの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理プロセスで使用されたロックリソースを解放します。

2PC ソリューションを使用する場合、最終段階でロックリソースを解放する必要があることに注意することが重要です。

信頼性の高いメッセージ最終一貫性ソリューション

信頼性の高いメッセージ最終一貫性ソリューションとは、トランザクション開始者がローカルトランザクションを完了してメッセージを送信すると、トランザクション参加者 (メッセージコンシューマー) が確実にメッセージを受信してトランザクションを正常に処理できることを意味します。このソリューションは、メッセージがトランザクション参加者に送信されている限り、最終的なトランザクションは一貫している必要があることを強調しています。

トランザクションイニシエーター (メッセージプロデューサー) はメッセージをメッセージミドルウェアに送信し、トランザクション参加者はメッセージミドルウェアからメッセージを受信します。トランザクションイニシエーターとメッセージミドルウェア、およびトランザクション参加者 (メッセージコンシューマー) とメッセージミドルウェアは、ネットワークを介して通信します。ネットワーク通信の不確実性により、分散トランザクションの問題が発生する可能性があります。そこで、具体的なプランではメッセージ確認サービスとメッセージ回復サービスを導入します。

信頼性の高いメッセージ最終整合性ソリューションを使用する場合、注意すべき問題がいくつかあります。

ローカルトランザクションとメッセージ送信の原子性の問題。
メッセージを受信するトランザクション参加者の信頼性の問題。
メッセージの繰り返し消費の問題 (べき等性を実現する必要がある)。

TCCプログラム

TCC は 3 つの段階に分かれています。

試行段階では、ビジネスチェック (一貫性) とリソース予約 (分離) を実行します。この段階は単なる予備的な操作です。これと後続の Confirm により、完全なビジネスロジックを形成できます。
確認段階では、送信内容を確認します。 Try ステージのすべてのブランチトランザクションが正常に実行された後、Confirm が実行されます。通常、TCC を使用する場合、確認フェーズではエラーが発生しないことが想定されます。つまり、Try が成功する限り、Confirm も成功します。確認フェーズで実際にエラーが発生した場合は、再試行メカニズムまたは手動処理が必要になります。
キャンセルフェーズでは、ビジネス実行エラーによりロールバックが必要になったときに、ブランチトランザクションをキャンセルし、予約済みのリソースを解放します。通常、TCC を使用する場合、キャンセルフェーズも確実に成功することが前提となります。キャンセルフェーズで実際にエラーが発生した場合は、再試行メカニズムまたは手動処理が必要になります。

TCC 分散ソリューションを使用する場合は、空のロールバック、べき等性、中断などの問題に注意する必要があります。

ベストエフォート通知制度

このソリューションは、次の図に示すように、複数の異なるシステム間でのデータの最終的な一貫性を確保するため主に使用されます。

ベストエフォート通知ソリューションを使用する場合は、べき等性とデータ取得操作に注意する必要があります。

さて、今日はこれで終わりです。各分散トランザクションソリューションについては後ほど詳しく紹介します。また次回お会いしましょう！！

この記事はWeChatの公開アカウント「Glacier Technology」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Glacier Technology 公式アカウントまでご連絡ください。

<<: メンガー: 大規模分散強化学習アーキテクチャ

>>: 分散キャップ定理と基底理論の簡単な分析!