Classic Queues
What is a Classic Queue
A RabbitMQ classic queue (the original queue type) is a versatile queue type suitable for use cases where data safety is not a priority because the data stored in classic queues is not replicated. Classic queues uses the non-replicated FIFO queue implementation.
If data safety is a priority, the recommendation is to use quorum queues and streams instead of classic queues.
Classic queues are the default queue type as long as the default queue type is not overridden for the virtual host.
Classic Queue Features
Classic queues fully support queue exclusivity, queue and message TTL (Time-To-Live), queue length limits, message priority, consumer priority and adhere to settings controlled using policies.
Classic queues support dead letter exchanges with the exception of at-least-once dead-lettering.
Classic queues do not support poison message handling, unlike quorum queues. Classic queues also do not support at-least-once dead-lettering, supported by quorum queues.
Per-consumer QoS prefetch should be preferred over global QoS prefetch, even though classic queues support both options. Global QoS prefetch is a deprecated feature that will be removed in RabbitMQ 4.0.
While classic queues can be declared as transient, this makes queue removal difficult to reason about in case of node restarts during upgrades and such, so the use of transient queues is discouraged. Support for transient queues is deprecated and will be removed in RabbitMQ 4.0.
Classic queues is a non-replicated queue type starting with RabbitMQ 4.0. Quorum queues and streams provide a better alternative when high availability and data safety is required.
Persistence (Durable Storage) in Classic Queues
Classic queues use an on-disk index for storing message locations on disk as well as a message store for persisting messages.
Both persistent and transient messages are always persisted to disk except when:
- the queue is declared as transient or messages are transient
- messages are smaller than the embedding threshold (defaults to 4096 bytes)
- the queue is short (queues may keep up to 2048 messages in memory at most, depending on the consumer delivery rate)
In general messages are not kept in memory unless the rate of consumption of messages is high enough that the messages that are in memory are expected to be consumed within the next second. Classic queues keep up to 2048 messages in memory, depending on the consumer delivery rate. Larger messages are not read into memory until the moment when they have to be sent to consumers.
Persisted messages may be embedded in the queue or sent to a shared message store. The decision to store messages in the queue or in the shared message store is based on the size of the message, including headers. The shared message store is more efficient at handling larger messages, particularly when those messages are sent to multiple queues.
The message location is written in the queue's index. Each queue has one index. The queue is responsible for tracking messages location as well as their position in the queue, and it persists this information in the index.
Embedded messages are written in its queue index when using classic queues version 1; and in its per-queue message store when using classic queues version 2.
Larger messages are written to a shared message store. Each vhost has two such stores: one for persistent messages and one for transient messages, but they are usually considered together as the shared message store. All queues in the vhost use the same message store.
Classic Queue Storage Implementation Versions
There are currently two classic queue versions (implementation). Depending on the version, classic queues will use a different index for messages, as well as operate differently regarding the embedding of small messages in the index.