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

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

[[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 本以上のバラを購入するとします。