分散トランザクション ソリューションの検討: 8 つのソリューションの分析

分散トランザクション ソリューションの検討: 8 つのソリューションの分析

分散トランザクションの基本理論である CAP 理論と BASE 理論についてはすでに学習しました。理論に基づいて、さまざまな分散シナリオに対する業界の一般的なソリューションには、2PC、TCC、信頼性の高いメッセージの結果一貫性、ベストエフォート通知などのソリューションが含まれます。 **以下は、8 つの一般的な解決策 (Eight Wonders と名付けられている) をまとめたものです**。実際の分散システムでトランザクションをより効果的に使用できるようにします。 。

1.2PC

2 フェーズ コミット プロトコル (略して 2PC)。 2PC は、トランザクション プロセス全体を 2 つの段階に分割します。

• 1. 準備段階
• 2. コミットフェーズ

2は2つの段階、Pは準備段階、Cは提出段階を表します。

Oracle や MySQL などのコンピューター内の一部のリレーショナル データベースは、次に示すように 2 フェーズ コミット プロトコルをサポートしています。

• 準備フェーズ: トランザクション マネージャーは各参加者に準備メッセージを送信します。各データベース参加者はトランザクションをローカルで実行し、ローカルの Undo/Redo ログを書き込みます。現時点ではトランザクションはコミットされていません。 (UNDO ログは変更前のデータを記録し、データベースのロールバックに使用されます。一方、REDO ログは変更後のデータを記録し、トランザクションをコミットした後にデータ ファイルを書き込むために使用されます)
• コミット フェーズ: トランザクション マネージャーが参加者から実行失敗またはタイムアウト メッセージを受信すると、各参加者にロールバック メッセージを直接送信します。それ以外の場合はコミット メッセージを送信します。参加者は、トランザクション マネージャーの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理プロセスで使用されたロック リソースを解放します。

注意: ロックリソースは最後の段階で解放する必要があります

次の図は、2PC の 2 つの段階を成功と失敗の 2 つのケースに分けて示しています。

• 成功事例:

写真

• 異常事態:

写真

2PC の利点と欠点:

アドバンテージ

• シンプルで直感的: ロジックは明確で、理解しやすく、実装も簡単です。
• 原子性保証: 複数の分散ノードにわたるトランザクションの原子性を保証する機能。

欠点:

• 同期ブロッキング: 最初のステージではデータベース リソースをロックし、2 番目のステージが終了するまで待ってから解放する必要があるため、パフォーマンスが低下し、同時実行性の高いシナリオには適用できません。
• 単一障害点の問題。コーディネータが第 2 フェーズでクラッシュした場合、参加者はコミットするかロールバックするかがわからないため、指示を無期限に待機する可能性があります。これにより、システム全体が単一障害点に対して脆弱になります。
• データの不整合の問題: コーディネーターが第 2 フェーズで一部の参加者にコミット指示を送信したが、ネットワークの問題により他の参加者が指示を受信しなかった場合、指示を受信しなかった参加者はロールバックを選択する可能性があり、その結果、データの不整合が発生します。

2.3PC

3PC (3 フェーズ コミット) は、分散システム内の複数の参加者間でのトランザクション操作の一貫性と信頼性を確保するために使用される分散トランザクション プロトコルです。これは、2 フェーズ コミット (2PC) プロトコルに基づいて開発されており、2PC プロトコルで発生する可能性のあるトランザクションのハングの問題を解決します。

3PC プロトコルは、送信操作を準備段階、送信準備段階、送信段階の 3 つの段階に分割します。各ステージには対応する操作とプロトコルがあります。

準備フェーズ（CanCommit）：

• コーディネーター: すべての参加者に CanCommit 準備リクエストを送信し、トランザクションをコミットできるかどうかを尋ねます。
• 参加者: ローカル トランザクションを実行し、実行可能かどうかを確認し、実行可能な場合は「はい」を返し、実行できない場合は「いいえ」を返します。

事前コミット:

• コーディネーター：参加者からのフィードバックに基づいて提出準備をするかどうかを決定します

• すべての参加者が「コミット可能」を返した場合、コーディネータはすべての参加者にコミット要求を送信し、コミットの準備ができることを通知します。
• いずれかの参加者が「コミットできません」を返すか、タイムアウト期間内に応答しない場合は、コーディネーターはすべての参加者に中止要求を送信してトランザクションをキャンセルします。

コミットフェーズ (DoCommit/DoAbort):

• コーディネータがすべての参加者から確認コミット メッセージを受信すると、トランザクションをコミットするためにすべての参加者に最終コミット要求を送信します。
• コーディネータがいずれかの参加者から中止要求を受信した場合、またはコミット準備フェーズ中にすべての参加者から応答を受信しなかった場合、コーディネータはすべての参加者に中止要求を送信してトランザクションをキャンセルします。

2PC プロトコルに対する 3PC プロトコルの改善点は、準備フェーズが追加されたことです。これにより、参加者は準備フェーズ中にトランザクションを送信できるかどうかを知ることができ、トランザクションがハングする問題を回避できます。しかし、3PC プロトコルには、コーディネータの単一点障害やメッセージの損失などの問題がまだ残っているため、実際のアプリケーションでは一般的ではありません。一般的には、2PC や Saga などの分散トランザクション ソリューションがよく使用されます。

3.TCC

TCC は、Try、Confirm、Cancel の略です。 TCC では、各ブランチ トランザクションで、前処理の Try、確認の Confirm、キャンセルの Cancel の 3 つの操作を実装する必要があります。 Try はビジネス チェックとリソース予約を実行し、Confirm はビジネス確認を実行し、Cancel は Try の逆の操作、つまりロールバック操作を実行します。 TM はまず、すべてのブランチ トランザクションの try 操作を開始します。いずれかのブランチ トランザクションの try 操作が失敗した場合、TM はすべてのブランチ トランザクションの Cancel 操作を開始します。すべての試行操作が成功した場合、TM はすべてのブランチ トランザクションの確認操作を開始します。確認/キャンセル操作が失敗した場合、TM は再試行します。

• ブランチ取引の成功:

写真

• ブランチトランザクションが失敗する状況:

写真

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

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

TCCは3種類の例外処理に注意を払う必要がある

空のロールバック

TCC リソースの Try メソッドを呼び出さずに第 2 段階の Cancel メソッドが呼び出された場合、Cancel メソッドはこれが空のロールバックであることを認識し、直接成功を返す必要があります。

原因: ブランチ トランザクションがダウンしているか、ネットワークが異常な場合、ブランチ トランザクション呼び出しは失敗として記録されます。この時点では、Try フェーズは実行されません。障害が回復されると、分散トランザクションがロールバックされ、第 2 フェーズの Cancel メソッドが呼び出され、空のロールバックが行われます。

解決策は

重要なのは、この空のロールバックを識別することです。アイデアは非常にシンプルです。ステージが実行されたかどうかを知る必要があります。実行されると、通常のロールバックになります。実行されない場合は、空のロールバックになります。

冪等性

TCC の 2 フェーズ コミット再試行メカニズムではデータの不整合は発生しません。また、TCC の 2 フェーズ Try、Confirm、および Cancel インターフェイスで冪等性が保証されるため、リソースが再利用または解放されることはありません。べき等性制御が適切に行われないと、データの不整合などの重大な問題が発生する可能性があります。

解決策: 上記の「ブランチ トランザクション レコード」に実行ステータスを追加し、各実行の前にステータスを照会します。

サスペンション

中断とは、分散トランザクションの場合、Try インターフェイスの前に第 2 フェーズの Cancel インターフェイスが実行されることを意味します。

原因: RPC が分岐トランザクション試行を呼び出すと、まず分岐トランザクションが登録され、その後 RPC 呼び出しが実行されます。この時点で RPC 呼び出しのネットワークが混雑している場合、通常、RPC 呼び出しはタイムアウトになります。 RPC がタイムアウトすると、TM は RM に分散トランザクションをロールバックするように通知します。 RPC 要求は、ロールバックが完了するまで、参加者に届かず、実際に実行されない場合があります。 Try メソッドによって予約されたビジネス リソースは、分散トランザクションでのみ使用できます。分散トランザクションの最初の段階で予約されたビジネス リソースを誰も処理できません。この状態は停止と呼ばれ、ビジネス リソースが予約された後に処理できないことを意味します。

解決策: 第 2 フェーズが完了すると、第 1 フェーズを続行できなくなります。フェーズ 1 トランザクションを実行するときに、グローバル トランザクションの下の「ブランチ トランザクション レコード」テーブルにフェーズ 2 トランザクション レコードが既に存在するかどうかを判断します。その場合は、Try を実行しないでください。

TCC の利点と欠点:

TCC の利点:

• トランザクションは1つのフェーズが完了するとすぐにコミットされ、データベースリソースが解放され、良好なパフォーマンスが実現されます。
• グローバルロックを使用する必要がなく、最高のパフォーマンス
• データベーストランザクションに依存せず、補正操作に依存し、非トランザクションデータベースに使用できます。

TCCの欠点

• コード侵入があり、try、confirm、cancelインターフェースを手動で記述する必要があるため、面倒すぎる
• ソフトステート、トランザクションは最終的に一貫性を持つ
• 確認とキャンセルの失敗を考慮し、べき等な処理を行う必要がある

4. 分散型報酬取引（Saga）

Saga は長いトランザクションのためのソリューションです。大規模な分散トランザクションを複数の小さなローカル トランザクションに分割し、これらのローカル トランザクションを非同期メッセージングを通じて連結します。各ローカル トランザクションが正常に実行されると、次のトランザクションの実行をトリガーするメッセージが送信されます。ローカル トランザクションが失敗した場合、Saga はデータの一貫性を維持するために一連の補正操作を実行します。

分散型報酬取引（Saga）のメリットとデメリット

アドバンテージ

• 柔軟性: それぞれの小さなトランザクションを個別に管理できるようにすることで、システムの柔軟性が向上します。
• リソースのロックが削減されます。リソースを継続的に占有する必要がないため、システムの同時実行機能が向上します。
• フォールト トレランス: 障害を処理するための補償アクションを定義することで、システムのフォールト トレランスが強化されます。
• マイクロサービス アーキテクチャに適しています: トランザクションはサービス境界を越えて管理でき、各サービスは独自のトランザクションと補正ロジックを独立して処理できます。

欠点

• 複雑さ: Saga を実装するには、小さなトランザクションごとに補償操作を定義する必要があり、システムの複雑さが増します。
• データの一貫性: 即時の一貫性を保証することはできず、最終的な一貫性のみが保証されます。
• 補正操作の難しさ: 特にトランザクションに副作用がある場合、補正操作の実装が困難な場合があります。
• テストとデバッグ: 複数のサービスと補正ロジックが関係する場合、テストとデバッグはより困難になる可能性があります。

Saga パターンの使用を選択する場合は、ビジネス シナリオが最終的な一貫性に適しているかどうか、および補正ロジックを効果的に実装および管理できるかどうかを慎重に検討する必要があります。高い一貫性の保証が必要なシナリオでは、他のトランザクション管理メカニズムを考慮する必要がある場合があります。 Saga パターンは、適切な状況下では分散システムに柔軟性とフォールト トレランスをもたらすことができますが、その複雑さと実装の難しさについては慎重に考慮する必要があります。

5. 信頼性の高いメッセージの結果的一貫性

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

このソリューションは、以下に示すように、メッセージ ミドルウェアを使用して完成します。

写真

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

信頼性の高いメッセージ最終一貫性ソリューションでは、以下の問題を解決する必要があります。

1. ローカルトランザクションとメッセージ送信の原子性の問題

ローカル トランザクションとメッセージ送信の原子性の問題は、トランザクション イニシエーターは、ローカル トランザクションが正常に実行された後にメッセージを送信する必要があり、そうでない場合、メッセージが破棄されることです。つまり、ローカル トランザクションとメッセージ送信のアトミック性が実現され、両方が成功するか、両方が失敗します。ローカル トランザクションとメッセージ送信の原子性は、信頼性の高いメッセージ最終一貫性ソリューションを実装する上で重要な問題です。まず、メッセージを送信してからデータベースを操作するという操作を試してみましょう。

 begin transaction； //1.发送MQ //2.数据库操作commit transation;

この場合、メッセージは正常に送信されても​​データベース操作が失敗する可能性があるため、データベース操作とメッセージ送信の一貫性は保証されません。 2 番目の解決策は、最初にデータベース操作を実行してからメッセージを送信することです。

 begin transaction； //1.数据库操作//2.发送MQ commit transation;

この場合は問題はないようです。 MQ メッセージの送信が失敗すると、例外がスローされ、データベース トランザクションがロールバックされます。ただし、タイムアウト例外の場合、データベースはロールバックされますが、実際には MQ は正常に送信されているため、不整合が発生します。

2. 取引参加者によるメッセージ受信の信頼性

トランザクション参加者は、メッセージ キューからメッセージを受信でき、メッセージの受信が失敗した場合にメッセージの受信を繰り返すことができる必要があります。

3. メッセージの繰り返し消費の問題

ネットワーク 2 が存在するため、コンシューマー ノードがタイムアウトしても消費が成功した場合、メッセージ ミドルウェアはメッセージを繰り返し配信し、結果としてメッセージが繰り返し消費されることになります。メッセージの繰り返し消費の問題を解決するには、トランザクション参加者のメソッドのべき等性を実装する必要があります。

6. ローカルメッセージテーブルソリューション

ローカル メッセージ テーブル ソリューションは、もともと eBay によって提案されました。このソリューションの中核は、ローカル トランザクションを通じてデータ、ビジネス操作、およびメッセージの一貫性を確保し、スケジュールされたタスクを通じてメッセージをメッセージ ミドルウェアに送信することです。メッセージは、消費者に正常に送信されたことが確認された後に削除されます。

以下では、ポイントを取得するために登録する例を使用して説明します。ユーザー サービスとポイント サービスの 2 つのマイクロサービス インタラクションがあります。ユーザー サービスはユーザーの追加を担当し、ポイント サービスはポイントの増加を担当します。

写真

対話プロセス

• ユーザー登録ユーザーサービスは、新規ユーザーの追加やローカル取引における「ポイントメッセージログ」の増加を行います。 (ユーザー テーブルとメッセージ テーブルはローカル トランザクションを通じて一貫性が保たれます)

 begin transaction； //1.新增用户//2.存储积分消息日志commit transation;

この場合、ローカル データベース操作とストレージ ポイント メッセージ ログは同じトランザクション内にあり、ローカル データベース操作とメッセージ ログ記録操作はアトミックです。

• スケジュールされたタスクスキャンログ

考えてみてください: メッセージがメッセージ キューに送信されることを確認するにはどうすればよいでしょうか?

最初のステップの後、メッセージはメッセージ ログ テーブルに書き込まれます。独立したスレッドを開始して、メッセージ ログ テーブル内のメッセージを定期的にスキャンし、メッセージ ミドルウェアに送信できます。メッセージ ミドルウェアのフィードバックが成功したら、メッセージ ログを削除します。それ以外の場合は、スケジュールされたタスクの次のサイクルが再試行されるまで待機します。

• 消費ニュース

コンシューマーがメッセージを消費できることをどのように保証しますか?

ここで、MQ の ack (メッセージ確認) メカニズムを使用できます。消費者は MQ を聞きます。コンシューマーがメッセージを受信し、ビジネス処理が完了した後に MQ に ack (メッセージ確認) を送信すると、コンシューマーがメッセージの通常の消費を完了したことを意味します。 MQ はメッセージをコンシューマーにプッシュしなくなります。そうしないと、コンシューマーはコンシューマーへのメッセージの送信を再試行し続けます。

ポイント サービスは「ポイントの追加」メッセージを受信し、ポイントの追加を開始します。ポイントが正常に追加された後、メッセージ ミドルウェアに ack で応答します。そうしないと、メッセージ ミドルウェアはこのメッセージを繰り返し配信します。メッセージは繰り返し配信されるため、ポイント サービスの「ポイントの追加」機能はべき等である必要があります。

7. 最善の努力による通知の原則

ベストエフォート通知もメッセージベースの分散トランザクション ソリューションですが、100% のメッセージ配信の成功を保証するものではありません。仕組みは次のとおりです。

• ローカル トランザクションが正常に実行された後、システムは他の参加者またはサービスに通知しようとします。
• 通知操作はベストエフォート方式で実行されますが、失敗した場合、システムは無期限に再試行しません。
• このソリューションは通常、手動介入と組み合わせて使用​​されます。たとえば、通知が失敗した場合、システムはログを記録したり、アラームを送信したり、オペレーターが手動で処理するための管理インターフェイスを提供したりすることがあります。考えてみてください。ベストエフォート通知と信頼性の高いメッセージの一貫性の違いは何でしょうか?

さまざまな解決策のアイデア

信頼性の高いメッセージの一貫性: 通知を開始する側は、メッセージが送信され、通知を受信する側に確実に送信されるようにする必要があります。メッセージの信頼性は主に通知を開始する側によって保証されます。

• ベスト エフォート通知: 通知の発信者は、通知の受信者にビジネス処理の結果を通知するために最善の努力を払いますが、メッセージが受信されない可能性があります。この場合、通知の受信者は、ビジネス処理の結果を照会するために、イニシエーターのインターフェースを積極的に呼び出す必要があります。通知の信頼性は通知の受信者によって異なります。

両者のビジネスアプリケーションシナリオは異なる

• 信頼性の高いメッセージの一貫性: トランザクション プロセスのトランザクション一貫性に重点を置き、非同期でトランザクションを完了します。
• ベストエフォート通知: トランザクション後の通知業務、つまりトランザクション結果を確実に通知することに重点を置いています。

さまざまな技術的ソリューション

• 信頼性の高いメッセージの一貫性: 送信から受信までのメッセージの一貫性、つまりメッセージが送信され、受信される問題を解決します。
• ベスト エフォート通知: 送信から受信までのメッセージの一貫性は保証されず、メッセージ受信の信頼性メカニズムのみが提供されます。信頼できるメカニズムは、メッセージの受信者に通知するために最大限の努力をすることです。受信者がメッセージを受信できない場合、受信者はメッセージを積極的に問い合わせます（ビジネス処理結果）。

8. 分散ロック

一部のビジネス シナリオでは、分散ロックを使用すると、複数の分散ノードが同時に同じリソースを操作しないようにすることが効果的です。このメカニズムは、Redis や ZooKeeper などの分散調整サービスを使用することで実現できます。

適用シナリオ: 電子商取引のフラッシュセールでは、過剰販売を防ぐために、在庫数量を同時に変更できるリクエストが 1 つだけであることを保証する必要があります。このとき、Redis を分散ロックのバックエンド ストレージとして使用することで、フラッシュ セールの円滑かつ公正な進行を確保できます。

推奨シナリオ: 複数のノードを調整して共有リソースへのアクセスを制御する必要がある場合は、分散ロックが非常に効果的なソリューションです。たとえば、分散システムでは、複数のノードが同時に同じリソースを読み取ったり更新したりする必要がある場合、データの一貫性を確保し、競合状態を回避するために、同時実行制御に分散ロックを使用できます。