キューは一般的なデータ構造であり、その最大の特徴は先入れ先出しであり、最も基本的なデータ構造であるキューの応用範囲は非常に広いです。たとえば、駅で切符を買うために列に並んでいるときなどです。次の図を使用してキューを表すことができます:
ここで、a1、a2、および an はキュー内のデータを表します。データはキューの最後からキューに入れられ、キューの先頭からデキューされます。
メッセージ キュー (メッセージ キュー) は、基礎となるストレージ データ構造としてキュー (キュー) を使用するメソッドであり、メッセージ キュー間の通信を解決するために使用できます。分散メッセージ コンテナは、メッセージ ミドルウェアとも呼ばれます。
現在一般的に使用されているメッセージ キューには、ActiveMQ、RabbitMQ、Kafka、RocketMQ、Redis などが含まれます。
#メッセージキューとキューの違いは何ですか? 唯一の違いは、キューに入るときはプロデューサーと呼ばれ、キューから取り出されるときはコンシューマと呼ばれることです。 3. メッセージ キュー アプリケーション シナリオメッセージ キュー アプリケーション シナリオは非常に広範囲にわたります。以下に、より一般的なシナリオのいくつかをリストします。1. 分散シナリオ1.1. 非同期処理一般に、作成したプログラムは順番に (つまり同期的に) 実行されます。たとえば、電子商取引システムでの注文の例では、実行シーケンスは次のとおりです。 ユーザーが注文を送信します。ご注文完了後にポイントが加算されます。ポイント変更をSMSでお知らせします。 は、次のフローチャートで表すことができます。 #上記の順序で実行すると、各サービスに 1 秒かかるとすると、クライアントの3秒。ユーザーにとって 3 秒は明らかに耐えられませんが、これをどのように解決すればよいでしょうか?この問題を解決するには、非同期メソッドを使用できます。以下のフローチャートを参照してください: このようにして、ポイント サービスと SMS サービスはスレッドを使用して非同期に動作します。クライアントは完了するまでに 1 秒しかかかりません。ただし、この非同期アプローチは、同時実行性の低下という別の問題を引き起こします。ポイント サービスと SMS サービスの両方で注文サービスのスレッドを開く必要があるため、より多くのスレッドが開かれると、クライアントによる注文サービスへの同時アクセスが減少し、クライアントが注文を送信するまでの実際の時間が長くなる可能性があります。 1秒を超えます。では、非同期によって引き起こされる問題を解決するにはどうすればよいでしょうか? #上記のプロセスでは、メッセージ キューの役割を追加しました。まず、クライアント注文を送信し、その注文をメッセージ キューに書き込みます。すると、ポイント サービスと SMS サービスがメッセージ キュー内のメッセージを同時に消費します。このメソッドでは、注文サービスが追加の非同期スレッドを開く必要はありません。クライアントは 1 秒のリアルタイム消費を達成できます。 1.2. アプリケーションの分離 電子商取引システムを例に挙げて説明します。まず、以下のフローチャートを見てください。上の図のビジネス ロジック: クライアントは注文を作成するリクエストを開始します。注文を作成するときは、まず在庫を取得し、次に在庫を差し引く必要があります。これにより、注文システムと在庫の間に非常に密接な依存関係が形成されます。システム。この時点で在庫システムがダウンした場合、発注システムは在庫システムに依存しているため、現時点では発注システムが利用できなくなります。では、どうすれば解決できるでしょうか?
以下のメッセージ キューの使用フローチャートをご覧ください。
上記のプロセスでは、メッセージ キューを追加しました。まず、クライアントが注文作成リクエストを開始し、注文メッセージがメッセージ キューに書き込まれます。次に、在庫システムがメッセージ キュー内のメッセージをサブスクライブし、最後に在庫システムを非同期で更新します。在庫システムがダウンした場合でも、発注システムは在庫システムに直接依存しないため、発注システムは顧客の要求に正常に応答できます。これにより、アプリケーションの分離が実現します。
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 サイトの他の関連記事を参照してください。