A virtual host provides a way to segregate applications using the same RabbitMQ instance. Different users can have different access privileges to different virtual hosts and queues and exchanges can be created, so they only exist in one virtual host.

When a producer publishes a message to a RabbitMQ broker, the messages are sent to an exchange. Exchanges are responsible for routing the messages to different queues. An exchange accepts messages from the producer and routes the messages to queues based on header attributes, bindings, and routing keys.

A binding is a connection between an exchange and a queue. Routing key is an attribute in the message, which helps the exchange to route the messages to queues.

The following types of exchanges are available in RabbitMQ:

Direct Exchange

A direct exchange delivers messages to queues based on a message routing key. In a direct exchange, the message is routed to the queues whose binding key matches the routing key of the message.

Fanout Exchange

A fanout exchange routes messages to all of the queues that are bound to it.

Topic Exchange

The topic exchange does a wildcard match between the routing key and the routing pattern specified in the binding.

Headers Exchange

Headers exchanges use the message header attributes for routing and routes messages to queues based on header values.

After a message is delivered to the consumer, RabbitMQ marks the message for deletion. To ensure that RabbitMQ delivers the messages to the consumer and the consumer handles the message successfully, RabbitMQ uses acknowledgements. The consumer sends an acknowledgement to RabbitMQ that the message has been successfully received, processed, and that RabbitMQ can delete the message.

If a consumer connection is lost and the consumer is unable to send an acknowledgement to RabbitMQ, RabbitMQ considers that the message was not processed completely and re-queues the message. If there are any other consumers online at the same time, RabbitMQ redelivers the message.

In automatic acknowledgement mode, RabbitMQ considers the message to be successfully delivered immediately after the message is sent. Automatic message acknowledgements increases the performance and throughput, but reduces the safety of message delivery.

If a consumer connection is lost, the message sent by RabbitMQ is lost.

In negative acknowledgement mode, a consumer is unable to process a delivery immediately but other consumers might be able to process the message. RabbitMQ re-queues message for another consumer to receive and handle the message.

To ensure that the message published by the producer has reached the RabbitMQ server and the RabbitMQ server handles the message successfully, RabbitMQ sends an acknowledgement to the publisher using the same mechanism used for consumer acknowledgements.

RabbitMQ uses Dead Letter Routing to republish a message to an exchange when any one of the following event occurs:

The message is negatively acknowledged by a consumer and is not re-queued by the RabbitMQ broker.
The message expires after it exceeds the time to live period.
The message was dropped because its queue exceeded a length limit.

The dead lettered messages are routed to the dead letter exchange specified in the same virtual host. Dead lettered messages are routed to the dead letter exchanges based on the routing key specified for the queue or the routing keys that the message were originally published with.

RabbitMQ uses heartbeats to detect any disrupted connections or defends idle connections that might be terminated. The heartbeat timeout determines the time period after which the RabbitMQ server and client considers the connection as unreachable.

Queues in RabbitMQ that are defined as durable are persisted to disk and can survive a broker restart. A durable queue does not ensure that the messages routed to that queue can survive a broker restart. In a durable queue, only persistent messages can survive a broker restart.

RabbitMQ messages consist of headers and a body. Headers are attributes set on a RabbitMQ message to control message delivery in RabbitMQ queues. Headers are set by the producer when it publishes a message and the consumer after it receives the message.

For example, you can use the following headers:

rabbitmq.ROUTING_KEY. The routing key used to deliver a message to the queue. The routing key specified in the header overrides the value specified in the RabbitMQ connection.
rabbitmq.DELIVERY_MODE. If the value is set to 2, RabbitMQ ensures that messages are persistent in a durable queue and can survive a broker restart.
rabbitmq.EXPIRATION. Specifies the time period after which a message will expire in a queue.
rabbitmq.EXCHANGE_OVERRIDE_NAME. Specifies the target exchange name that overrides the exchange name specified in the RabbitMQ connection.
rabbitmq.EXCHANGE_NAME. Name of the exchange that the consumer received the message from.