序文

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

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

データベース トランザクション (略称: トランザクション) は、データベース管理システムの実行プロセスにおける論理単位です。これは、データベース操作の有限のシーケンスで構成されます。これらの操作はすべて実行されるか、まったく実行されません。それは分割できない作業単位です。

データベース トランザクションの一般的な特性には、原子性、一貫性、独立性、永続性 (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 つのサービスに分割されます。これらのサービスは異なるマシン (ノード) に展開されており、対応するデータベース (ゴールド コイン データベース、注文データベース、ギフト データベース) も異なるノードにあります。

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

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

ビジネスの発展に伴い、データベース内のデータはますます大きくなっています。データが数千万を超えると、それを異なるデータベースとテーブルに分割する必要があります（以前は、会社でデータベースとテーブルを分割するために mycat を使用していましたが、後に sharding-jdbc を使用しました）。分割データベースでは、データが異なるノードに分散されます。たとえば、一部は深センのコンピューター ルームにあり、一部は北京のコンピューター ルームにあります。それを保証するためにローカルトランザクションを使用したい場合、それは役に立たないでしょう。分散トランザクションは依然として必要です。

たとえば、A が B に 10 元を送金する場合、A のアカウントデータは北京のデータセンターにあり、B のアカウントデータは深センのデータセンターにあります。プロセスは次のとおりです。

CAP理論とBASE理論

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

CAP理論

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

一貫性（C）：

一貫性とは、データが複数のコピーにわたって一貫性を維持できるかどうかを指します。たとえば、あるパーティション ノードでデータが更新されると、他のパーティション ノードで読み取られるデータも更新されたデータになります。

可用性

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

パーティション許容度（P）：

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

選択の説明 CA は、パーティション耐性を放棄し、一貫性と可用性を強化します。これは、実際には従来のスタンドアロン データベースの選択です。 AP は、一貫性、パーティション耐性、および可用性を放棄します。これは、多くの分散システム設計の選択です。 CP は可用性を放棄し、一貫性とパーティション耐性を追求します。ネットワークの問題により、システム全体が直接利用できなくなります

ベース理論

BASE 理論は CAP における AP の拡張です。当社のビジネス システムでは、システムの可用性とパーティション耐性と引き換えに一貫性を犠牲にすることを検討しています。 BASE は、Basically Available (基本的に利用可能)、Soft state (ソフト状態)、Eventually Consistent (最終的に一貫性がある) という 3 つのフレーズの略語です。

基本的に利用可能

基本的な可用性: システム全体の障害ではなく、ローカル障害をサポートすることで実現されます。ユーザーが 5 つのデータベース サーバーに分割されている場合、1 つのユーザー データベースで障害が発生すると、その特定のホスト上のユーザーの 20% にのみ影響し、他のユーザーには影響はありません。

ソフトステート

ソフト状態、一定期間同期が取れない状態になる可能性がある

最終的に一貫性

最終的な一貫性とは、常に強い一貫性を維持するのではなく、データが最終的に一貫性を持つことを意味します。

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

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

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

フェーズ2提出計画

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

第2段階の提出成功

準備フェーズでは、トランザクション マネージャーは各リソース マネージャーに準備メッセージを送信し、リソース マネージャーのローカル トランザクション操作が正常に実行された場合は成功を返します。

コミット実行フェーズでは、トランザクション マネージャーがすべてのリソース マネージャーから成功メッセージを受信すると、各リソース マネージャーにコミット メッセージを送信し、RM は TM の指示に従ってコミットを実行します。図に示すように:

フェーズ2の提出失敗

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

コミット実行フェーズ中に、トランザクション マネージャーがいずれかのリソース マネージャーが失敗したというメッセージを受信すると、各リソース マネージャーにロールバック メッセージを送信します。リソース マネージャーは、トランザクション マネージャーの指示に従ってローカル トランザクション操作をロールバックし、トランザクション処理プロセスで使用されるすべてのロック リソースを解放します。

2フェーズコミットの利点と欠点

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

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

TCC（補償メカニズム）

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 プロセス中に例外が発生した場合、プロセスはキャンセル ステージに入ります。

TCC 確認フェーズ:

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

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

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

TCC の利点と欠点

TCC ソリューションを使用すると、アプリケーションはデータベース操作の粒度をカスタマイズし、ロックの競合を減らし、パフォーマンスを向上させることができますが、次のような欠点もあります。

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

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

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

基本的な実装のアイデア

メッセージ送信者:

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

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

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

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

長所と短所:

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

ベストエフォート通知

最大通知とは何ですか?

ベストエフォート通知も分散トランザクション ソリューションです。以下は、法人向けオンラインバンキング振込の例です。

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

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

ベストエフォート通知ソリューション

ベスト エフォート通知を実装するには、MQ ack メカニズムを使用できます。

プラン

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

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

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

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

サガトランザクション

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

佐賀の紹介

• サガ = ロングライブトランザクション (LLT)
• LLT = T1 + T2 + T3 + ... + Ti (Tiはローカルショートトランザクション)
• 各ローカルトランザクションTiには対応する補償Ciがある

サガの処刑命令

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

佐賀の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 の欠点であり、トランザクション間の分離が欠如していることが原因です。