When using RabbitMQ for sending messages you basically have exchanges, queues and bindings. I’ve understood their idea and how they relate to each other, but I am not quite sure who sets up what.
Basically, I have three scenarios in my application.
Scenario 1: One publisher, several worker processes
What I want to achieve is one component that sends messages to a queue, and there shall be several worker processes that handle items in that queue. This seems quite easy to me. The setup is as follows:
- Exchange: 1 exchange with type ‘direct’
- Queue: 1 queue
- Binding: The queue is bound to the exchange
Whenever a message is sent to the exchange, it gets delivered to the queue, and the worker processes get their tasks.
Everything shall be durable.
So who sets up what? In my opinion:
- Producer creates exchange
- Producer creates queue (as there currently may be no worker processes running, and the message would be lost otherwise if there was no queue)
- Producer does the binding of the queue to the exchange
- Consumers simply listen on the queue
Right?
Scenario 2: One publisher, several subscribers, volatile messages
The second scenario is quite different. Basically, it’s a pub / sub scenario where each message is send to every currently listening client. If a client goes offline, it does not receive messages any longer and they are not stored anywhere for him. This means the following setup:
- Exchange: 1 exchange with type ‘fanout’
- Queue: n queues, one for each consumer
- Binding: Each queue needs to be bound to the exchange
So who sets up what? In my opinion:
- Producer creates exchange
- Consumer creates queue (as it is its own queue, and the producer can not know whoever is interested in the messages)
- Consumer creates binding for its queue to the exchange
- Consumer listens to its queue
Right?
Scenario 3: One publisher, several subscribers, durable messages
Basically the same as scenario 2, but the messages should not be lost if a consumer goes offline. In my opinion this should not change anything – right?
I think what you say is right except on Scenario 3.
If messages should not be lost if a consumer goes offline then you need durable queues and the queues can’t be auto_delete’d.
Everything else seems right to me.
In the case of scenario 2 you could also let RabbitMQ auto-generate queue names for you and then let those queues be auto-delete’d once the consumer disconnects.