分散トランザクション ソリューションの検討: 8 つのソリューションの分析分散トランザクションの基本理論である CAP 理論と BASE 理論についてはすでに学習しました。理論に基づいて、さまざまな分散シナリオに対する業界の一般的なソリューションには、2PC、TCC、信頼性の高いメッセージの結果一貫性、ベストエフォート通知などのソリューションが含まれます。 **以下は、8 つの一般的な解決策 (Eight Wonders と名付けられている) をまとめたものです**。実際の分散システムでトランザクションをより効果的に使用できるようにします。 。 1.2PC2 フェーズ コミット プロトコル (略して 2PC)。 2PC は、トランザクション プロセス全体を 2 つの段階に分割します。
2は2つの段階、Pは準備段階、Cは提出段階を表します。 Oracle や MySQL などのコンピューター内の一部のリレーショナル データベースは、次に示すように 2 フェーズ コミット プロトコルをサポートしています。
注意: ロックリソースは最後の段階で解放する必要があります 次の図は、2PC の 2 つの段階を成功と失敗の 2 つのケースに分けて示しています。
写真
写真 2PC の利点と欠点:アドバンテージ
欠点:
2.3PC3PC (3 フェーズ コミット) は、分散システム内の複数の参加者間でのトランザクション操作の一貫性と信頼性を確保するために使用される分散トランザクション プロトコルです。これは、2 フェーズ コミット (2PC) プロトコルに基づいて開発されており、2PC プロトコルで発生する可能性のあるトランザクションのハングの問題を解決します。 3PC プロトコルは、送信操作を準備段階、送信準備段階、送信段階の 3 つの段階に分割します。各ステージには対応する操作とプロトコルがあります。 準備フェーズ(CanCommit):
事前コミット:
コミットフェーズ (DoCommit/DoAbort):
2PC プロトコルに対する 3PC プロトコルの改善点は、準備フェーズが追加されたことです。これにより、参加者は準備フェーズ中にトランザクションを送信できるかどうかを知ることができ、トランザクションがハングする問題を回避できます。しかし、3PC プロトコルには、コーディネータの単一点障害やメッセージの損失などの問題がまだ残っているため、実際のアプリケーションでは一般的ではありません。一般的には、2PC や Saga などの分散トランザクション ソリューションがよく使用されます。 3.TCCTCC は、Try、Confirm、Cancel の略です。 TCC では、各ブランチ トランザクションで、前処理の Try、確認の Confirm、キャンセルの Cancel の 3 つの操作を実装する必要があります。 Try はビジネス チェックとリソース予約を実行し、Confirm はビジネス確認を実行し、Cancel は Try の逆の操作、つまりロールバック操作を実行します。 TM はまず、すべてのブランチ トランザクションの try 操作を開始します。いずれかのブランチ トランザクションの try 操作が失敗した場合、TM はすべてのブランチ トランザクションの Cancel 操作を開始します。すべての試行操作が成功した場合、TM はすべてのブランチ トランザクションの確認操作を開始します。確認/キャンセル操作が失敗した場合、TM は再試行します。
写真
写真 TCCは3つの段階に分かれています
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 の利点:
TCCの欠点
4. 分散型報酬取引(Saga)Saga は長いトランザクションのためのソリューションです。大規模な分散トランザクションを複数の小さなローカル トランザクションに分割し、これらのローカル トランザクションを非同期メッセージングを通じて連結します。各ローカル トランザクションが正常に実行されると、次のトランザクションの実行をトリガーするメッセージが送信されます。ローカル トランザクションが失敗した場合、Saga はデータの一貫性を維持するために一連の補正操作を実行します。 分散型報酬取引(Saga)のメリットとデメリットアドバンテージ
欠点
Saga パターンの使用を選択する場合は、ビジネス シナリオが最終的な一貫性に適しているかどうか、および補正ロジックを効果的に実装および管理できるかどうかを慎重に検討する必要があります。高い一貫性の保証が必要なシナリオでは、他のトランザクション管理メカニズムを考慮する必要がある場合があります。 Saga パターンは、適切な状況下では分散システムに柔軟性とフォールト トレランスをもたらすことができますが、その複雑さと実装の難しさについては慎重に考慮する必要があります。 5. 信頼性の高いメッセージの結果的一貫性信頼性の高いメッセージ最終一貫性ソリューション: トランザクション イニシエーターがローカル トランザクションを完了してメッセージを送信すると、トランザクション参加者 (メッセージ コンシューマー) は確実にメッセージを受信し、トランザクションを正常に処理します。このソリューションは、メッセージがトランザクション参加者に送信されている限り、最終的なトランザクションは一貫している必要があることを強調しています。 このソリューションは、以下に示すように、メッセージ ミドルウェアを使用して完成します。 写真 トランザクション イニシエーター (メッセージ プロデューサー) はメッセージをメッセージ ミドルウェアに送信し、トランザクション参加者はメッセージ ミドルウェアからメッセージを受信します。トランザクション イニシエーターとメッセージ ミドルウェア、およびトランザクション参加者 (メッセージ コンシューマー) とメッセージ ミドルウェアは、ネットワークを介して通信します。ネットワーク通信の不確実性により、分散トランザクションの問題が発生する可能性があります。 信頼性の高いメッセージ最終一貫性ソリューションでは、以下の問題を解決する必要があります。1. ローカルトランザクションとメッセージ送信の原子性の問題ローカル トランザクションとメッセージ送信の原子性の問題は、トランザクション イニシエーターは、ローカル トランザクションが正常に実行された後にメッセージを送信する必要があり、そうでない場合、メッセージが破棄されることです。つまり、ローカル トランザクションとメッセージ送信のアトミック性が実現され、両方が成功するか、両方が失敗します。ローカル トランザクションとメッセージ送信の原子性は、信頼性の高いメッセージ最終一貫性ソリューションを実装する上で重要な問題です。まず、メッセージを送信してからデータベースを操作するという操作を試してみましょう。 この場合、メッセージは正常に送信されてもデータベース操作が失敗する可能性があるため、データベース操作とメッセージ送信の一貫性は保証されません。 2 番目の解決策は、最初にデータベース操作を実行してからメッセージを送信することです。 この場合は問題はないようです。 MQ メッセージの送信が失敗すると、例外がスローされ、データベース トランザクションがロールバックされます。ただし、タイムアウト例外の場合、データベースはロールバックされますが、実際には MQ は正常に送信されているため、不整合が発生します。 2. 取引参加者によるメッセージ受信の信頼性トランザクション参加者は、メッセージ キューからメッセージを受信でき、メッセージの受信が失敗した場合にメッセージの受信を繰り返すことができる必要があります。 3. メッセージの繰り返し消費の問題ネットワーク 2 が存在するため、コンシューマー ノードがタイムアウトしても消費が成功した場合、メッセージ ミドルウェアはメッセージを繰り返し配信し、結果としてメッセージが繰り返し消費されることになります。メッセージの繰り返し消費の問題を解決するには、トランザクション参加者のメソッドのべき等性を実装する必要があります。 6. ローカルメッセージテーブルソリューションローカル メッセージ テーブル ソリューションは、もともと eBay によって提案されました。このソリューションの中核は、ローカル トランザクションを通じてデータ、ビジネス操作、およびメッセージの一貫性を確保し、スケジュールされたタスクを通じてメッセージをメッセージ ミドルウェアに送信することです。メッセージは、消費者に正常に送信されたことが確認された後に削除されます。 以下では、ポイントを取得するために登録する例を使用して説明します。ユーザー サービスとポイント サービスの 2 つのマイクロサービス インタラクションがあります。ユーザー サービスはユーザーの追加を担当し、ポイント サービスはポイントの増加を担当します。 写真 対話プロセス
この場合、ローカル データベース操作とストレージ ポイント メッセージ ログは同じトランザクション内にあり、ローカル データベース操作とメッセージ ログ記録操作はアトミックです。
考えてみてください: メッセージがメッセージ キューに送信されることを確認するにはどうすればよいでしょうか?
コンシューマーがメッセージを消費できることをどのように保証しますか?
ポイント サービスは「ポイントの追加」メッセージを受信し、ポイントの追加を開始します。ポイントが正常に追加された後、メッセージ ミドルウェアに ack で応答します。そうしないと、メッセージ ミドルウェアはこのメッセージを繰り返し配信します。メッセージは繰り返し配信されるため、ポイント サービスの「ポイントの追加」機能はべき等である必要があります。 7. 最善の努力による通知の原則ベストエフォート通知もメッセージベースの分散トランザクション ソリューションですが、100% のメッセージ配信の成功を保証するものではありません。仕組みは次のとおりです。
さまざまな解決策のアイデア信頼性の高いメッセージの一貫性: 通知を開始する側は、メッセージが送信され、通知を受信する側に確実に送信されるようにする必要があります。メッセージの信頼性は主に通知を開始する側によって保証されます。
両者のビジネスアプリケーションシナリオは異なる
さまざまな技術的ソリューション
8. 分散ロック一部のビジネス シナリオでは、分散ロックを使用すると、複数の分散ノードが同時に同じリソースを操作しないようにすることが効果的です。このメカニズムは、Redis や ZooKeeper などの分散調整サービスを使用することで実現できます。 適用シナリオ: 電子商取引のフラッシュセールでは、過剰販売を防ぐために、在庫数量を同時に変更できるリクエストが 1 つだけであることを保証する必要があります。このとき、Redis を分散ロックのバックエンド ストレージとして使用することで、フラッシュ セールの円滑かつ公正な進行を確保できます。 推奨シナリオ: 複数のノードを調整して共有リソースへのアクセスを制御する必要がある場合は、分散ロックが非常に効果的なソリューションです。たとえば、分散システムでは、複数のノードが同時に同じリソースを読み取ったり更新したりする必要がある場合、データの一貫性を確保し、競合状態を回避するために、同時実行制御に分散ロックを使用できます。 |
<<: テンセントクラウドは、人気ゲーム「幻獣パル」のマルチプレイヤー専用サーバーの唯一の公式パートナーとなった。
>>: ガートナー: インフラストラクチャ プラットフォーム エンジニアリングを活用してクラウド ネイティブ プラットフォームを管理する
Weibo、SNS、モバイルインターネットなどの新しい形態の出現により、伝統的なインターネットモデル...
Pyramid Server は 2007 年に設立され、2010 年に正式に会社として運営を開始し...
初心者のウェブマスターはウェブサイトの最適化に取り組み始めたばかりで、間違いなく期待を抱いています。...
2003 年に設立されたこの古いホスティング会社 a2hosting は、私たちに驚きをもたらしまし...
米国現地時間5月8日午前10時(北京時間5月9日)、3日間にわたる2018 Google I/O 開...
[[361071]]ほとんどのユーザーは、Java リフレクションの使用に精通しています。特にオープ...
タオバオが1年前に最大のライバルであるWeChatに対して排除命令を出したことは誰もが知っている。そ...
2022 年になると、セキュリティと価値が DevOps の 2 つの重要な側面になります。しかし、...
月収10万元の起業の夢を実現するミニプログラム起業支援プラントラフィックサイトは多くのSEO専門家が...
あなたがウェブマスターであれば、仮想サービスを提供するウェブマスターであっても、製品を販売するウェブ...
[[440211]]調査会社カナリスは、2021年第3四半期の中国クラウドサービス市場レポートを発表...
過去 1 年間で、N 個の Web サイトを構築し、N 個のドメイン名を手元に持っています。N 個の...
Hostga の「言葉では言い表せない」ホストは、その安定性で知られており、仮想ホストランキングでも...
Cloudcone は、KVM 仮想化、ロサンゼルス MC データ センター、1Gbps 帯域幅を備...
では、どのページが価値がないのかをどのように判断すればよいのでしょうか。「ユーザーの需要」を判断基準...