分散トランザクションについてもう知らないとしたら、私は本当に怒ります!

最近、分散トランザクションに関するブログ投稿をいくつか読んでメモを取り、この記事にまとめました。

[[317468]]

画像はPexelsより

データベーストランザクション

データベース トランザクション (略称: トランザクション) は、データベース管理システムの実行プロセスにおける論理単位であり、有限の一連のデータベース操作で構成されます。

これらの操作はすべてか、いずれも実行されないかのいずれかであり、分割できない作業単位です。

データベース トランザクションのいくつかの典型的な特性:

• 原子性
• 一貫性
• 分離
• 耐久性

略語はACIDです。

• アトミック性: トランザクションは全体として実行され、そこに含まれるデータベースに対するすべての操作は、すべて実行されるか、まったく実行されないかのいずれかになります。
• 一貫性: トランザクションの開始前と終了前、およびトランザクションの開始後と終了後にデータが破壊されないことを意味します。たとえば、口座 A から口座 B に 10 元を送金した場合、送金の成功または失敗に関わらず、A と B の合計金額は変わりません。
• 分離: 複数のトランザクションが同時にアクセスされる場合、トランザクションは互いに分離されます。つまり、1 つのトランザクションが他のトランザクションの操作に影響を与えることはありません。つまり、物事は互いに干渉し合うべきではないのです。
• 永続性: トランザクションが完了すると、トランザクションによってデータベースに加えられた変更はデータベース内に永続化されます。

取引の実施原則

地方問題

単一のサーバーおよび単一のリレーショナル データベース上の従来のトランザクションは、ローカル トランザクションです。ローカル トランザクションはリソース マネージャーによって管理されます。 JDBC トランザクションは、非常に典型的なローカル トランザクションです。

トランザクションログ

InnoDB トランザクション ログには、REDO ログと UNDO ログが含まれます。

REDO ログ: 通常は物理ログであり、特定の行がどのように変更されたかではなく、データ ページに対する物理的な変更を記録します。送信後に物理データ ページを復元するために使用されます。

UNDOログ（ロールバックログ） ：物理ログを記録するREDOログとは異なる論理ログです。

レコードが削除されると、対応する挿入レコードが UNDO ログに記録され、レコードが更新されると、対応する逆の更新レコードが記録されると考えられます。

トランザクションACID特性の実装アイデア：

• アトミック性: これは、UNDO ログを使用することで実現されます。トランザクション実行中にエラーが発生した場合、またはユーザーがロールバックを実行した場合、システムは UNDO ログを通じてトランザクション開始時の状態に戻ります。
• 永続性: これは、REDO ログを使用して実現されます。 REDO ログが永続的である限り、システムがクラッシュしても、REDO ログを通じてデータを復元できます。
• 分離: トランザクションはロックと MVCC を通じて相互に分離されます。
• 一貫性: 同時実行状況でのロールバック、リカバリ、分離を通じて一貫性を実現します。

分散トランザクション

分散トランザクションとは、トランザクション参加者、トランザクションをサポートするサーバー、リソース サーバー、およびトランザクション マネージャーが、異なる分散システムの異なるノードに配置されていることを意味します。

簡単に言えば、分散トランザクションとは分散システムにおけるトランザクションを指し、異なるデータベース ノード間のデータの一貫性を確保するために存在します。

分散トランザクションがなぜ必要なのでしょうか?以下は 2 つの側面から説明されます。

マイクロサービスアーキテクチャにおける分散トランザクション

インターネットの急速な発展に伴い、軽量かつ明確な機能区分を持つマイクロサービスが歴史の舞台に登場しました。

たとえば、ユーザーがライブ放送ギフトを購入するために注文を行うサービスは、コインサービス (coinService)、注文サービス (orderService)、ギフトサービス (giftService) の 3 つのサービスに分割されます。

これらのサービスは異なるマシン (ノード) に展開されており、対応するデータベース (ゴールド コイン データベース、注文データベース、ギフト データベース) も異なるノードにあります。

ユーザーがギフトを購入する注文をすると、ギフト データベース、ゴールド コイン データベース、注文データベースは異なるノード上にあります。ローカルトランザクションは使用できません。では、異なるデータベース (ノード) 上のデータの一貫性を確保するにはどうすればよいでしょうか?これには分散トランザクションが必要です。

シャーディングによる分散トランザクション

ビジネスが発展するにつれて、データベースのデータはますます大きくなり、データポイントは 1,000 万を超えます。それをシャーディングする必要があります (同社は以前は Mycat を使用してデータベースとテーブルをシャーディングし、その後 Sharding-JDBC を使用しました)。

分割データベースでは、データが異なるノードに分散されます。たとえば、一部は深センのコンピューター ルームにあり、一部は北京のコンピューター ルームにあります。それを保証するためにローカルトランザクションを使用したい場合、それは役に立たないでしょう。分散トランザクションは依然として必要です。

たとえば、A が B に 10 元を送金します。A のアカウント データは北京のデータ センターにあり、B のアカウント データは深センのデータ センターにあります。

プロセスは次のとおりです。

CAP理論とBASE理論

分散トランザクションを学ぶには、CAP 理論と BASE 理論を理解する必要があります。

CAP理論

分散システムの基本理論である CAP 理論は、分散システムでは一貫性、可用性、分断耐性の 3 つの要素のうち 2 つだけが同時に達成できることを意味します。

一貫性 ( C): 一貫性とは、データが複数のコピー間で一貫性を維持できるかどうかを指します。

たとえば、あるパーティション ノードでデータが更新されると、他のパーティション ノードで読み取られるデータも更新されたデータになります。

可用性(A): 可用性とは、システムによって提供されるサービスが常に利用可能であり、ユーザーからの各操作要求に対して常に限られた時間内に結果を返すことができることを意味します。ここでのポイントは「限られた時間内で」と「結果を返す」ことです。

パーティション耐性 ( P): 分散システムでネットワーク パーティション障害が発生した場合でも、一貫性と可用性を満たすサービスを提供できる必要があります。

ベース理論

BASE 理論は CAP における AP の拡張です。当社のビジネス システムでは、システムの可用性とパーティション耐性と引き換えに一貫性を犠牲にすることを検討しています。

BASE は、Basically Available、Soft State、Eventually Consistent という 3 つのフレーズの略語です。

基本的に利用可能：基本的に利用可能です。これは、システム全体の障害ではなく、ローカル障害をサポートすることによって実現されます。

ユーザーが 5 つのデータベース サーバーに分割されている場合、1 つのユーザー データベースで障害が発生すると、その特定のホスト上のユーザーの 20% にのみ影響し、他のユーザーには影響はありません。

ソフト状態：ソフト状態。状態はしばらくの間同期されない可能性があります。

最終的に一貫性がある: 最終的に一貫性がある。重要なのは、データが常に強く一貫していることではなく、最終的に一貫していることだけです。

分散トランザクションのためのいくつかのソリューション

分散トランザクションソリューションには主に次のものがあります。

• 2PC（2フェーズコミット）ソリューション
• TCC (試行、確認、キャンセル)
• ローカルメッセージテーブル
• ベストエフォート通知
• サガトランザクション

フェーズ2提出計画

2 フェーズ コミット スキームは、一般的に使用される分散トランザクション ソリューションです。トランザクションの送信は、実行計画の準備と送信の 2 つの段階に分かれています。

第 2 フェーズの送信は成功しました。

• 準備フェーズでは、トランザクション マネージャーは各リソース マネージャーに準備メッセージを送信し、リソース マネージャーのローカル トランザクション操作が正常に実行された場合は成功を返します。
• コミット実行フェーズでは、トランザクション マネージャーがすべてのリソース マネージャーから成功メッセージを受信すると、各リソース マネージャーにコミット メッセージを送信し、RM は TM の指示に従ってコミットを実行します。

図に示すように:

フェーズ 2 の送信が失敗しました:

• 準備フェーズでは、トランザクション マネージャーは各リソース マネージャーに準備メッセージを送信します。リソース マネージャーのローカル トランザクション操作が正常に実行された場合は、成功が返されます。実行が失敗した場合は、失敗が返されます。
• コミット実行フェーズ中に、トランザクション マネージャーがいずれかのリソース マネージャーが失敗したというメッセージを受信すると、各リソース マネージャーにロールバック メッセージを送信します。

リソース マネージャーは、トランザクション マネージャーの指示に従ってローカル トランザクション操作をロールバックし、トランザクション処理プロセスで使用されるすべてのロック リソースを解放します。

2PC ソリューションは実装が簡単でコストも低いですが、次のような主な欠点があります。

• 単一障害点: トランザクション マネージャーに障害が発生すると、リソース マネージャーはロックされたままになります。
• パフォーマンスの問題: すべてのリソース マネージャーは、トランザクションのコミット フェーズ中に同期ブロック状態になり、コミットが完了するまでシステム リソースを占有するため、パフォーマンスのボトルネックが発生しやすくなります。
• データ一貫性の問題: 一部のリソース マネージャーが送信されたメッセージを受信し、一部が受信しない場合、データの不整合が発生します。

TCC（補償メカニズム）

TCC は補償メカニズムを採用しており、その中核となる考え方は、各操作ごとに、対応する確認と補償 (キャンセル) 操作を登録する必要があるというものです。

TCC (Try-Confirm-Cancel) は、ビジネス ロジックを分解して分散トランザクションを実装します。

特定のビジネス サービスの場合、TCC 分散トランザクション モデルでは、ビジネス システムが次の 3 つのロジックを実装する必要があります。

• 試行フェーズ: 実行を試行し、すべてのビジネスで一貫性チェックを完了し、必要なビジネス リソースを予約します。
• 確認ステージ: 試行ステージですでにチェックされているため、このステージではチェックなしでビジネスの送信を確認します。デフォルトでは、確認段階でエラーは発生しません。
• キャンセル フェーズ: ビジネス実行が失敗した場合、このフェーズに入り、試行フェーズで占有されていたすべてのビジネス リソースが解放され、確認フェーズで実行されたすべての操作がロールバックされます。

TCC 分散トランザクション モデルは、次の 3 つの部分で構成されます。

• メインビジネスサービス: メインビジネスサービスは、ビジネスアクティビティ全体の開始と完了を担当します。
• スレーブ ビジネス サービス: スレーブ ビジネス サービスは、ビジネス アクティビティ全体に参加し、マスター ビジネス サービスが呼び出す Try、Confirm、および Cancel 操作を実装します。
• ビジネス アクティビティ マネージャー: ビジネス アクティビティ マネージャーは、トランザクション ステータスの記録、ビジネス サービスからの確認操作の呼び出し、ビジネス サービスからのキャンセル操作の呼び出しなど、ビジネス アクティビティ全体を管理および制御します。

次に、TCC が分散トランザクションを実装するプロセスをシミュレートするために、ユーザーがギフトを購入する注文を出す例を取り上げます。ユーザー A の残高は 100 枚のゴールド コインで、ギフトを 5 個所有していると仮定します。 Aは10枚の金貨を費やして、10本のバラを買う注文をしました。残高、注文、ギフトはすべて異なるデータベースに保存されます。

TCC のトライフェーズ:

• 注文ステータスが確認待ちの注文レコードを生成します。
• ユーザーAのアカウントのゴールドコインの残高を90に更新し、ゴールドコイン10枚（予約済みのビジネスリソース）を凍結します。
• ユーザーのギフト数量を 5 に設定し、事前増分数量を 10 に設定します。
• 試行が成功すると、確認フェーズに入ります。
• Try プロセス中に例外が発生した場合、プロセスは Cancel フェーズに入ります。

TCC 確認フェーズ:

• 注文ステータスが「支払済み」に更新されます。
• ユーザー残高を 90 に更新し、0 に凍結します。
• ユーザーギフトの数は 15 に更新され、事前増分は 0 です。
• 確認プロセス中に例外が発生した場合、プロセスはキャンセル段階に入ります。
• 確認プロセスが正常に実行されると、トランザクションは終了します。

TCC のキャンセル フェーズ:

• 注文ステータスを「キャンセル」に変更します。
• ユーザーの残高を 100 に戻します。
• ユーザーのギフト数量を 5 に更新します。

TCC ソリューションにより、アプリケーションはデータベース操作の粒度をカスタマイズできるため、ロックの競合が減り、パフォーマンスが向上します。

しかし、次のような欠点もあります。

• アプリケーションは非常に侵襲性が高く、ビジネス ロジックは Try、Confirm、Cancel の 3 つの段階で実装する必要があります。
• ネットワーク障害やシステム障害など、さまざまな障害理由に応じて、異なるロールバック戦略を実装する必要があります。これは実装が難しく、通常は TCC オープン ソース フレームワーク、ByteTCC、TCC トランザクション、および Himly の助けを借りて行われます。

ローカルメッセージテーブル

eBay は当初、分散トランザクションの問題を解決するためにローカル メッセージ テーブル ソリューションを提案しました。このソリューションは現在業界で広く使用されています。その中心的なアイデアは、分散トランザクションをローカル トランザクションに分割して処理することです。

基本的な実装フローチャートを見てみましょう。

基本的な実装のアイデアは次のとおりです。

メッセージ送信者:

• メッセージ ステータスに関連する情報を記録するには、メッセージ テーブルが必要です。
• ビジネス データ テーブルとメッセージ テーブルは同じデータベース内にあるため、同じローカル トランザクション内にある必要があります。
• ビジネス データを処理し、ローカル トランザクションでメッセージ テーブルに書き込んだ後、メッセージを MQ メッセージ キューに書き込みます。
• メッセージはメッセージ コンシューマーに送信されます。送信に失敗した場合は再試行されます。

メッセージコンシューマー:

• メッセージ キュー内のメッセージを処理し、独自のビジネス ロジックを完成させます。
• この時点で、ローカルトランザクションが正常に処理された場合、処理が成功したことを意味します。
• ローカル トランザクションが失敗した場合、実行が再試行されます。
• ビジネス障害の場合は、ロールバックなどの操作を実行するように通知するビジネス補償メッセージがメッセージ プロデューサーに送信されます。

プロデューサーとコンシューマーは、ローカル メッセージ テーブルを定期的にスキャンし、処理されなかったメッセージや失敗したメッセージを再送信します。信頼性の高い自動調整およびアカウント補充ロジックがあれば、このソリューションは依然として非常に実用的です。

利点と欠点: このソリューションの利点は、分散トランザクションの問題を適切に解決し、最終的な一貫性を実現することです。欠点は、メッセージ テーブルがビジネス システムに結合されることです。

ベストエフォート通知

最大通知とは何ですか?ベストエフォート通知も分散トランザクションソリューションです。

以下は、企業のオンラインバンキング振込の例です。

• 企業のオンライン バンキング システムはフロントエンド インターフェイスを呼び出し、振替ページにジャンプします。
• 企業のオンラインバンキングは、振替システムインターフェースを呼び出します。
• 振替システムは振替処理を完了し、企業のオンラインバンキングシステムに振替結果通知を開始します。通知が失敗した場合、転送システムは戦略に従って通知を繰り返します。
• 企業のオンライン バンキング システムが通知を受信しない場合、転送システムのインターフェイスを積極的に呼び出して転送結果を照会します。
• 送金システムでは送金返金などの状況が発生する場合があり、定期的に口座の調整が行われます。

ベスト エフォート通知スキームの目的は、通知の発信者が特定のメカニズムを使用して、ビジネス処理の結果を受信者に通知するためにベスト エフォートを行うことです。

ベストエフォート通知実装メカニズムは次のとおりです。

ベストエフォート通知ソリューション: ベストエフォート通知を実装するには、MQ ACK メカニズムを使用できます。  

解決策は次のとおりです。

• イニシエーターは MQ に通知を送信します。
• 通知を受信する側は MQ メッセージをリッスンします。
• 通知受信者はメッセージを受信後、処理を完了し、ACK で応答します。
• 通知の受信者が ACK で応答しない場合、MQ は 1 分、5 分、10 分などの間隔で通知を繰り返します。
• 通知の受信者は、メッセージ校正インターフェイスを使用してメッセージの一貫性を確保できます。

移転業務実施フローチャート：

対話プロセスは次のとおりです。

• ユーザーは送金システムに資金の送金を要求します。
• 転送システムは転送を完了し、転送結果を MQ に送信します。
• 企業のオンラインバンキングシステムは MQ を監視し、振替結果の通知を受け取ります。メッセージが受信されない場合、MQ は通知を繰り返し送信します。転送結果を受信し、転送ステータスを更新します。
• 企業のオンライン バンキング システムは、振替システムの振替結果照会インターフェイスを積極的に照会して、振替ステータスを更新することもできます。

サガトランザクション

Saga トランザクションは、プリンストン大学の Hector Garcia-Molina 氏と Kenneth Salem 氏によって提案されました。

基本的な考え方は、長いトランザクションを複数のローカルの短いトランザクションに分割し、それらを Saga トランザクション コーディネータが調整することです。正常に終了した場合は正常に完了します。ステップが失敗した場合、補正操作が逆の順序で 1 回呼び出されます。

サガの紹介:

• Saga = Long Live Transaction (LLT)。
• LLT = T1 + T2 + T3 + ... + Ti (Ti はローカルショートトランザクションです)。
• 各ローカルトランザクション Ti には対応する補償 Ci があります。

サガの処刑命令:

• 通常の状態: T1 T2 T3 ... Tn
• 異常時：T1 T2 T3 C3 C2 C1

Saga には 2 つの回復戦略があります。

• ローカル サブトランザクションが失敗した場合は、完了したトランザクションを補償して、後方に回復します。たとえば、異常な状況での実行順序は、T1 T2 Ti Ci C2 C1 です。
• すべてのサブトランザクションが最終的に成功すると想定して、順方向に回復します。つまり、失敗したトランザクションを再試行します。実行順序: T1、T2、...、Tj(失敗)、Tj(再試行)、...、Tn。

たとえば、ユーザーが注文し、10 元を支払って 10 本以上のバラを購入するとします。

• T1 = 注文する
• T2 = ユーザーから10元を差し引く
• T3=ユーザーがバラを10本追加
• T4 = 在庫からバラ10本を引いた値
• C1 = 注文をキャンセル
• C2 = ユーザーに10元を追加
• C3 = ユーザーマイナス10本のバラ
• C4 = 在庫＋バラ10本

トランザクションが T4 で異常ロールバックされたと仮定します。 C4 がバラを在庫に戻そうとすると、ユーザーのバラがすべて使い果たされていることがわかります。これは Saga の欠点であり、トランザクション間の分離が欠如していることが原因です。

この問題は、次の解決策によって解決できます。

• アプリケーション レベルで論理ロックのロジックを追加します。
• セッション レベルの分離により、シリアル操作が保証されます。
• ビジネスレベルでは、資金のこの部分は資金を事前に凍結することで分離されます。
• 業務遂行中は、現状をタイムリーに読み取ることで最新情報を取得します。

参考文献と謝辞:

• 実践スキル |分散トランザクションを学ぶのに役立つ記事
• 誰かが分散トランザクションについて再度尋ねてきたら、この記事を渡してください
• 分散トランザクションとソリューションについてお話ししましょう
• MySQLトランザクション実装の原則
• MySQL トランザクション ログ (REDO ログと UNDO ログ) の詳細な分析
• Saga 分散トランザクション ソリューションと実践
• 分散トランザクション ソリューションのベスト エフォート通知