Producer sends message to an Exchange, which routes the message to appropriate queue based on Bindings.
Bindings
Consumer
Exchange Types
direct
topic
headers
fanout
Broadcasts all the messages it receives to all the queues it knows.
default (unnamed)
Routes the message received to the queue named equal to the name specified in routing_key by Publisher.
Work Queue/Task Queue
Avoid waiting for a time-consuming task.
Schedule the task for asynchronous execution.
Encapsulate the task as a message and send to a queue (work queue)
A worker process consumes the message from the queue and dequeues only after successful task completion
Message durability
RabbitMQ sends messages to consumers in a round-robin manner, message no. n will be delivered to consumer no. n modulo m, where m is the number of consumers connected
Consumers need to acknowledge the message back to broker for broker to mark the message for deletion.
A message is re queued for delivery when the consumer process dies, there are no message timeouts
Acknowledgements must be send on the same channel that received the delivery.
For a message to be durable/persistent in face of broker restarts
Queue must be declared durable
Message must be declared persistent by producer
Even with above, it is possible that messages are lost because -
Broker may crash after RabbitMQ broker has accepted the message, but not persisted it yet
Broker does not persist each message to disk as it arrives, for performance issues, messages are kept in memory for a while and persisted in batches
Fair dispatch - RabbitMQ delivers messages in round robin order, without taking into account the number of messages being processed by a consumer. This can result in load imbalance. To address it set prefetchCount to 1 on consumer side. With this if a message is being processed by a consumer, broker will not send another message to it. Instead, the message will be send to the next available consumer.