メッセージの送信にRabbitMQを使用する場合、基本的に交換、キュー、およびバインディングがあります。彼らのアイデアとそれらが互いにどのように関係しているかは理解しましたが、誰が何を設定したのかよくわかりません。
基本的に、アプリケーションには3つのシナリオがあります。
シナリオ1：1つのパブリッシャー、複数のワーカープロセス
私が達成したいのは、キューにメッセージを送信する1つのコンポーネントであり、そのキュー内のアイテムを処理する複数のワーカープロセスが存在する必要があります。これは私には非常に簡単に思えます。設定は次のとおりです。
- 交換：タイプ'direct'の1つの交換
- キュー：1キュー
- バインド：キューは交換にバインドされます
メッセージが取引所に送信されるたびに、メッセージはキューに配信され、ワーカープロセスがタスクを取得します。
すべてが耐久性があります。
では、誰が何を設定するのでしょうか。私の意見では：
- プロデューサーが交換を作成します
- プロデューサーはキューを作成します（現在、実行中のワーカープロセスがない可能性があり、キューがない場合はメッセージが失われるため）
- プロデューサーは、キューを交換にバインドします
- 消費者は単にキューで耳を傾けます
右？
シナリオ2：1つのパブリッシャー、複数のサブスクライバー、揮発性メッセージ
2番目のシナリオはまったく異なります。基本的に、これはpub / subシナリオであり、各メッセージが現在リッスンしているすべてのクライアントに送信されます。クライアントがオフラインになると、メッセージは受信されなくなり、メッセージはどこにも保存されません。これは、次の設定を意味します。
- 交換：タイプ「ファンアウト」との交換1回
- キュー：n個のキュー、各コンシューマーに1つ
- バインド：各キューを交換にバインドする必要があります
では、誰が何を設定するのでしょうか。私の意見では：
- プロデューサーが交換を作成します
- コンシューマーはキューを作成します（それは独自のキューであり、プロデューサーはメッセージに関心のある人を知ることができないため）
- コンシューマーは、交換へのキューのバインディングを作成します
- 消費者はそのキューに耳を傾けます
右？
シナリオ3：1つのパブリッシャー、複数のサブスクライバー、永続的なメッセージ
基本的にシナリオ2と同じですが、コンシューマーがオフラインになってもメッセージが失われることはありません。私の意見では、これは何も変わらないはずです-そうですか？