バックグラウンド
大規模なインターネット システムでは、ビジネス ロジックが比較的複雑であるか、大規模で同時実行性の高いシナリオのために技術アーキテクチャの複雑さが増しています. このとき、複雑なシステムを分離する必要があります. ここで、メッセージ ミドルウェアはシステムを分離するために使用されます。
コンテンツ
メッセージミドルウェアの使用
最初にいくつかの概念を理解しましょう。
結合:結合度とも呼ばれ、モジュール間の関連度の尺度です。結合の強さは、モジュール間のインターフェイスの複雑さ、モジュールの呼び出し方法、およびインターフェイスを介して転送されるデータの量によって異なります。
モジュール間の結合度とは、制御関係、呼び出し関係、データ転送関係など、モジュール間の依存関係を指します。一般的に言えば、モジュール間の接続が多いほど、結合が強くなり、独立性が低くなります。
結合と結合は通常、モジュールの独立性の度合いを測定するための標準として、ソフトウェア設計で使用されます。モジュールを分割する基準の 1 つは、凝集度が高く、結合度が低いことです。
メッセージ ミドルウェア:プラットフォームに依存しないデータ交換に効率的で信頼性の高いメッセージ配信メカニズムを使用し、データ通信に基づいて分散システムを統合します。メッセージパッシングとメッセージキューイングモデルを提供することにより、分散環境でプロセス間通信をスケーリングします。
メッセージ キューには、主に次の機能があります。非同期処理、トラフィック ピーク クリッピング、およびアプリケーション デカップリング。
- 非同期処理。生産側は消費者側からの応答を待つ必要がなく、直接返されるため、応答時間とスループットが向上します。
- トラフィック クリッピング。ピーク期間中のトラフィックを均等化するために、コンシューマは自身の速度に従ってトラフィックを処理できます。同時に、リソース使用率を向上させるためにピーク期間中にあまり多くのリソースを追加する必要はありません。
- アプリケーションの分離。生産者と消費者は互いに依存する必要はありません。
適用シナリオ
1. 非同期処理:
シナリオの説明: ユーザーが注文した後、確認のために電子メールとテキスト メッセージを送信する必要があります。2 つの従来のアプローチがあり、1 つはシリアルで、もう 1 つはパラレルです。
- a. シリアルモード: 注文情報をデータベースに書き込んだ後、電子メールを送信してからテキスト メッセージを送信し、上記の 3 つのタスクがすべて完了したらクライアントに戻ります。ここでの問題の 1 つは、電子メールやテキスト メッセージは必要なく、単なる通知であり、このアプローチではクライアントが不要なイベントを待機することです。
- b. 並列モード: 注文情報をデータベースに書き込んだ後、電子メールとテキスト メッセージを同時に送信し、上記の 3 つのタスクが完了した後にクライアントに戻る並列モードでは、処理時間を改善できます。
3 つのサービス ノードがそれぞれ 50ms 使用し、シリアル使用時間が 150ms、パラレル使用時間が 100ms であるとします。並列処理によって処理時間は改善されましたが、前述のように、電子メールと SMS は、ユーザーによる Web サイトの通常の使用には影響を与えません.クライアントは、注文の成功を表示するために送信の完了を待つ必要はありません. . データベースへの書き込み後に返されるはずです。
一般的な同期方式で処理すると、システムのパフォーマンスが非常に遅くなります。
- c. メッセージ待ち行列
メッセージキューの導入後は、メールやテキストメッセージなどの送信はビジネスロジックに必要ないため、非同期処理を行うことができます。
このことからわかるように、メッセージ キューの導入後、ユーザーの応答時間は、データベースへの書き込み時間 + メッセージ キューへの書き込み時間に等しくなります。応答時間は、シリアルの 3 倍、パラレルの 2 倍です。
2. アプリケーションの分離:
シナリオの説明: ある宝物ダブル 11 ショッピング カーニバルでは、ユーザーが注文した後、注文システムは在庫システムに通知して、在庫のロック操作を実行する必要があります. 従来の方法では、注文システムは在庫システムのインターフェースを呼び出します.
このアプローチには欠点があります。在庫システムに障害が発生すると、注文が失敗します。注文システムと在庫システムは高度に結合されており、解決策はメッセージ キューを導入することです。
- 注文システム: ユーザーが注文した後、注文システムは永続化プロセスを完了し、メッセージをメッセージ キューに書き込み、ユーザーの注文を返します。
- 注文しました。在庫システムは、注文メッセージをサブスクライブし、注文メッセージを取得して、倉庫操作を実行します。
インベントリ システムに障害が発生した場合、メッセージ キューは、メッセージの損失を引き起こすことなく、メッセージの信頼性の高い配信を保証することもできます。
3. フロー ピーク クリッピング:
トラフィック ピーク クリッピングは、一般的に seckill システムで広く使用されています。
シナリオの説明: 通常、ショッピング サイトの seckill アクティビティにより、過剰なトラフィックが原因でアプリケーションがハングアップします. この問題を解決するには、アプリケーションのフロント エンドにメッセージ キューを追加します.
効果:
- アクティブな人数を制御でき、一定のしきい値を超える注文は直接破棄されます。
- 短期的な大流量破砕システムを緩和できます。
変更後の処理フローは次のとおりです。
サーバーはユーザーのリクエストを受け取ると、まずそれをメッセージ キューに書き込み、追加されたメッセージ キューの長さが最大値を超えると、ユーザーのリクエストを直接破棄するか、エラー ページにジャンプします。
seckill ビジネスは、メッセージキュー内のリクエスト情報に従ってフォローアップ処理を実行します。
やっと:
上記では、メッセージ ミドルウェアによる複雑なシステムの分離を紹介しました。メッセージ ミドルウェアの導入は、システムの応答性と使いやすさの向上にも役立ちます。
メッセージ ミドルウェアは、今日のアーキテクチャ テクノロジで非常に一般的に使用されているツールです。
前の章のチュートリアル
Architectural Thinking Growth Series チュートリアル (3) - 数億のトラフィック ピークに「キャッシュ」がどのように対処するか
一連のチュートリアル
私のコラム
以上で、すべての紹介は終了です
-------------------------------
-------------------------------
私について(個人ドメイン名、私に関する詳細情報)
私のオープンソース プロジェクト コレクション Github
皆さんと一緒に学び、成長し、激励できることを楽しみにしています, O(∩_∩)O ありがとう
質問の交換へようこそ。個人的な QQ 469580884 を追加できます。
または、私のグループ番号 751925591を追加して、コミュニケーションの問題について一緒に話し合ってください
嘘について話さないで、ただ実行者になりなさい
話は安いです、コードを見せてください