ホームページ  >  記事  >  Java  >  RabbitMQ インストール (Windows) サンプル チュートリアル

RabbitMQ インストール (Windows) サンプル チュートリアル

零下一度
零下一度オリジナル
2017-07-18 14:44:501477ブラウズ

管理バックエンド

rabbitmqには独自の管理バックエンドが付属しており、インストール後に設定して有効にする必要があります
rabbitmqインストールディレクトリのsbinディレクトリに移動して実行します
rabbitmq-pluginsでrabbitmq_managementを有効にします
rabbitmqサービスを再起動して有効にします
http://localhost:15672/ を開き、管理の背景を参照します
ユーザー名とパスワードはすべてゲストです

設定手順


コマンドラインを使用してキューリストを表示します

sbin>rabbitmqctl list_queues  
sbin>rabbitmqctl list_queues name messages_ready messages_unacknowledged

コマンドラインを使用して交換リスト

sbin>rabbitmqctl list_exchanges

キューを定義します

RabbitMQ では異なるパラメータを使用できません 既存のキューを再定義します。

RabbitMQ では、異なるパラメータを使用して既存のキューを再定義することはできず、再定義しようとするプログラムにはエラーが返されます

信頼性

メッセージが失われないようにするには、メッセージの永続性を設定する必要がありますキューも耐久性がなければなりません。
ただし、これはまだ 100% 信頼できるわけではありません。メッセージを受信した後、永続化が完了する前に RabbitMQ がクラッシュした場合、メッセージは失われるからです。

繰り返し処理

次のシナリオを考えてみましょう (前提: キューとメッセージは永続的です):

  1. コンシューマーはメッセージ msgA を受信しましたが、これは処理途中で完了しておらず、ACK 確認も開始されていませんでした。

    この時点で、RabbitMQ はクラッシュしました。
  2. コンシューマはメッセージ msgA の処理を​​完了しました。
  3. RabbitMQ が再起動されたときに、msgA が処理されていないことが判明したため、msgA が再度コンシューマに送信されました。
  4. このシナリオでは、メッセージ msgA が 2 回処理されるため、コンシューマ側には繰り返し処理を防ぐメカニズムが必要です。
ACK

ACK 確認は、コンシューマがメッセージの処理を完了したことを RabbitMQ に伝えるだけであり、論理的な処理が成功したことを通知するものではありません。ビジネス処理が失敗した場合でも、ACK 確認は必要です。一般に、ビジネス上の理由で障害が発生した場合、再試行しても問題は解決しないからです。ネットワークの中断、マシンの停電などによる障害のみ、再試行が必要です。

ビジネス負荷が特定のコンシューマに集中するのを防ぎます

channel.basicQos(prefetchCount);

prefetchCount=1

を設定し、最後のメッセージがそのコンシューマに割り当てられるまで、一度に 1 つのコンシューマに 1 つのメッセージのみを割り当てるように RabbitMQ に指示しますメッセージは確認されて処理されます。このようにして、実際の処理条件に基づいて、アイドル状態のコンシューマにメッセージが毎回割り当てられます。


デフォルトの Exchange についてprefetchCount=1
,告诉RabbitMQ 每次只给一个消费者分配一个消息,直到上一个分配给该消费者的消息被确认处理完成。这样一来,消息就会根据实际处理情况,每次都分配给空闲的消费者。

关于默认Exchange

默认Exchange隐式地绑定到每一个队列,路由key为队列名。不能对其进行显式绑定或解绑。并且它是不可删除的。

The default exchange is implicitly bound to every queue, with a routing key equal to the queue name. It is not possible to explicitly bind to, or unbind from the default exchange. It also cannot be deleted.

消息传递的基本过程

发布者发布一个消息
-->exchange接收消息(如果发布者没有指定特定的Exchange则使用默认Exchange),并根据exchange的类型,按照一定的路由规则,把消息路由给每一个符合路由规则的队列(如果没有匹配的队列,则消息被丢弃)
-->队列将消息发送给订阅该队列的某一个消费者(如果没有消费者则消息保留在队列中,知道有消费者消费该消息)

Topic Exchange的通配符

星号匹配一个单词(注意,不是一个字母)

* (star) can substitute for exactly one word.
井号匹配任意个单词
#

デフォルトの Exchange は暗黙的に各キューにバインドされており、ルーティング キーはキュー名です。明示的にバインドまたはアンバインドすることはできません。そしてそれは削除できません。

デフォルトの交換は、キュー名と同じルーティングキーを使用して、すべてのキューに暗黙的にバインドされます。また、デフォルトの交換に明示的にバインドしたり、デフォルトの交換からバインドを解除したりすることはできません。また、メッセージを渡すこともできません。基本プロセス

発行者がメッセージを発行

--> Exchange がメッセージを受信 (発行者が特定の Exchange を指定しない場合は、デフォルトの Exchange が使用されます)、交換の種類と特定のルーティング ルールに従って、メッセージは、ルーティング ルールに準拠する各 A キューにルーティングされます (一致するキューがない場合、メッセージは破棄されます)

---> キューは、キューに登録されているコンシューマにメッセージを送信します (コンシューマが存在しない場合、メッセージは、コンシューマーがメッセージを消費するまでキューに残ります)

トピック交換ワイルドカード

スターは単語と一致します (文字ではなく注意してください)

🎜* (スター) は正確に置き換えることができます1 つの単語。🎜ポンド記号 任意の数の単語に一致します🎜# (ハッシュ) は、0 個以上の単語の代わりに使用できます。🎜🎜🎜AMQP プロトコルの必須フラグと即時フラグの役割🎜🎜必須フラグと即時フラグは、 AMQP プロトコルの Basic.pulish メソッド内 2 つのフラグ ビットには、メッセージ配信中に宛先に到達できない場合にメッセージをプロデューサーに返す機能があります。具体的な違いは次のとおりです: 🎜🎜1. 必須フラグ 🎜🎜必須フラグが true に設定されている場合、交換が独自のタイプとメッセージのルートキーに基づいて適格なキューを見つけられない場合、basic.return メソッドが呼び出されて、または、必須が false に設定されている場合、ブローカーは上記の状況でメッセージを直接破棄します。 🎜🎜2. 即時フラグ ビット 🎜🎜 即時フラグ ビットが true に設定されている場合、Exchange がメッセージをキューにルーティングするときに、対応するキューにコンシューマーが存在しないことが検出された場合、メッセージはキューに置かれません。列。メッセージrouteKeyに関連付けられたすべてのキュー(1つ以上)にコンシューマがない場合、メッセージはbasic.returnメソッドを通じてプロデューサに返されます。 🎜

以上がRabbitMQ インストール (Windows) サンプル チュートリアルの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。