キューは一般的なデータ構造であり、その最大の特徴は先入れ先出しであり、最も基本的なデータ構造であるキューの応用範囲は非常に広いです。たとえば、駅で切符を買うために列に並んでいるときなどです。次の図を使用してキューを表すことができます:
ここで、a1、a2、および an はキュー内のデータを表します。データはキューの最後からキューに入れられ、キューの先頭からデキューされます。
メッセージ キュー (メッセージ キュー) は、基礎となるストレージ データ構造としてキュー (キュー) を使用するメソッドであり、メッセージ キュー間の通信を解決するために使用できます。分散メッセージ コンテナは、メッセージ ミドルウェアとも呼ばれます。
現在一般的に使用されているメッセージ キューには、ActiveMQ、RabbitMQ、Kafka、RocketMQ、Redis などが含まれます。
上の図のビジネス ロジック: クライアントは注文を作成するリクエストを開始します。注文を作成するときは、まず在庫を取得し、次に在庫を差し引く必要があります。これにより、注文システムと在庫の間に非常に密接な依存関係が形成されます。システム。この時点で在庫システムがダウンした場合、発注システムは在庫システムに依存しているため、現時点では発注システムが利用できなくなります。では、どうすれば解決できるでしょうか?
以下のメッセージ キューの使用フローチャートをご覧ください。
上記のプロセスでは、メッセージ キューを追加しました。まず、クライアントが注文作成リクエストを開始し、注文メッセージがメッセージ キューに書き込まれます。次に、在庫システムがメッセージ キュー内のメッセージをサブスクライブし、最後に在庫システムを非同期で更新します。在庫システムがダウンした場合でも、発注システムは在庫システムに直接依存しないため、発注システムは顧客の要求に正常に応答できます。これにより、アプリケーションの分離が実現します。
1.3. トラフィックのピーク削減
この点で最も一般的な例は、フラッシュ セール システムです。一般に、フラッシュ セール活動の瞬間的なトラフィックは非常に多くなります。すべてのトラフィックがフラッシュ セール システムに流れると、フラッシュ セール システムが圧倒されてしまいます。メッセージ キューでは、バースト トラフィックを効果的にバッファリングして「ピーク クリッピング」効果を実現できます。
フラッシュ セール シナリオを使用してトラフィックのピークカットを説明します。まず次のフローチャートを見てみましょう:
上記のプロセスでは、フラッシュセールサービス 上流サービスといい、発注サービス、在庫サービス、残高サービスを総称して下流サービスといいます。クライアントがフラッシュ セール リクエストを開始します。クライアントからリクエストを受信した後、フラッシュ セール サービスは注文を作成し、在庫を変更し、残高を差し引きます。これがフラッシュ セールの基本的なビジネス シナリオです。
ダウンストリーム サービスは同時に 1,000 個の同時リクエストしか処理できず、アップストリーム サービスは 10,000 個の同時リクエストを処理でき、クライアントが 10,000 個のリクエストを開始すると、ダウンストリーム サービスが処理できる同時リクエストの量を超えます。そのため、ダウンストリームのサービスがダウンします。この時点で、メッセージ キューに参加してダウンタイムの問題を解決できます。以下のメッセージ キューに参加するフローチャートを見てください。
上記のフローチャートにメッセージ キューを追加して、サービスが送信された 10,000 リクエストをどのように処理するかを説明しました。すべてのリクエストはメッセージ キューに書き込まれ、ダウンストリーム サービスはメッセージ キュー内のフラッシュ セール リクエストをサブスクライブし、独自のビジネス ロジック操作を実行します。
簡単な例を見てみましょう。アップストリーム サービスは依然として 10,000 個の同時リクエストを処理できますが、ダウンストリーム サービスは依然として 1,000 個の同時リクエストしか処理できません。この時点では、1,000 個の同時リクエストをメッセージに保存できるようにします。列。アップストリームのフラッシュ セール サービスは 10,000 件の同時リクエストを受信しましたが、メッセージ キューに保存できるリクエストは 1,000 件のみです。超過したリクエストはメッセージ キューに保存されず、「システムがビジーです。ください」というプロンプトとともにクライアントに直接返されます。待って!" 。これは、いわゆるトラフィック ピーク クリッピング シナリオです。これは、ダウンストリーム サービスが処理できる同時実行の量によって決まります。ダウンストリーム サービスは 1,000 件の同時リクエストしか処理できないため、メッセージ キューに保存できるフラッシュ セールは 1,000 件のみで、超過したフラッシュ セール リクエストはすべてクライアント プロンプトに返されます。これにより、ダウンストリーム サービスの通常の応答が保証され、ダウンストリーム サービスのダウンタイムが発生せず、システムの可用性が向上します。
プログラムを堅牢にするために、通常、エラーログ、操作ログなどのさまざまなログ機能をプログラムに追加します。など、以下のフローチャートを参照してください。
上記のフローチャートは、ログを同期的に記録するプロセスです。同期ロギングの処理を行うと、処理全体にかかる時間が長くなり、業務システムのダウンタイムも発生しやすくなります(データベースが破損している場合、データベースへのログ記録操作でエラーが発生します)。メッセージ キューを使用してログ送信を最適化できます。以下のフローチャートを参照してください。
メッセージ キューに参加すると、システムに費やす時間が短縮され、アプリケーション システムの分離機能も実現されます。
メッセージ キューの主な機能はメッセージの送受信であり、内部に効率的な通信メカニズムが組み込まれているため、メッセージ通信に非常に適しています。
メッセージ キューに基づいたポイントツーポイント チャット システムを開発したり、多数の受信者にメッセージをブロードキャストするブロードキャスト システムを開発したりできます。
以上がJavaメッセージキューの応用シナリオは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。