concept delivery - mode in category rabbitmq

This is an excerpt from Manning's book RabbitMQ in Depth. Login to get full access to this book.

The message properties contained in the header frame are a predefined set of values specified by the Basic.Properties data structure (figure 3.2). Some properties, such as delivery-mode, have well-defined meanings in the AMQP specification, whereas others, such as type, have no exact specification.

Figure 3.2. Basic.Properties, including the deprecated cluster-id property from AMQP-0-8

In some cases, RabbitMQ uses well-defined properties to implement specific behaviors with regard to the message. An example of this is the previously mentioned delivery-mode property. The value of delivery-mode will tell RabbitMQ if it’s allowed to keep the message in memory when the message is placed in a queue or if it must store the message to disk first.

Because memory IO is inherently faster than disk IO, specifying delivery-mode as 1 will deliver your messages with as little latency as possible. In my web application login use case, the choice of delivery mode may be easier than in other use cases. Although it’s desirable not to lose any login events if a RabbitMQ server fails, it’s usually not a hard requirement. If member login event data is lost, it’s not likely the business will suffer. In that case, we’d use delivery-mode:1. But if you’re using RabbitMQ to publish financial transaction data, and your application architecture is focused on guaranteed delivery instead of message throughput, you can enable persistence by specifying delivery-mode:2. As illustrated in figure 3.10, when specifying a delivery mode of 2, messages are persisted to a disk-backed queue.