Classic vs Quorum Queue in RabbitMQ: Key Differences and Usage
Classic queues are the traditional queues with optional mirroring for replication, while Quorum queues use the Raft consensus algorithm for stronger data safety and automatic leader election. Quorum queues provide better fault tolerance and consistency but may have slightly higher latency compared to classic queues.Quick Comparison
This table summarizes the main differences between Classic and Quorum queues in RabbitMQ.
| Feature | Classic Queue | Quorum Queue |
|---|---|---|
| Replication Method | Optional mirroring with manual setup | Built-in Raft consensus replication |
| Durability | Durable if configured, but risk of split-brain | Strong durability with consensus and leader election |
| Fault Tolerance | Depends on mirroring setup, possible data loss | Automatic leader failover, no data loss |
| Performance | Lower latency, higher throughput | Slightly higher latency due to consensus overhead |
| Use Case | Simple workloads, legacy support | Critical data, high availability, consistency |
| Message Ordering | Preserved per queue | Preserved with quorum consensus |
Key Differences
Classic queues are the original RabbitMQ queues that can be made highly available by enabling mirroring across nodes. This mirroring is manual and can lead to split-brain scenarios where data might diverge if network partitions occur. They offer good performance with low latency but require careful configuration for fault tolerance.
Quorum queues are newer and designed to replace mirrored classic queues. They use the Raft consensus algorithm to replicate messages across a group of nodes, ensuring strong consistency and automatic leader election. This means if one node fails, another takes over without data loss or split-brain issues. The trade-off is slightly higher latency due to consensus overhead.
Quorum queues are better suited for critical workloads where data safety and availability are priorities, while classic queues remain useful for simpler or legacy scenarios.
Classic Queue Example
This example shows how to declare a classic queue with mirroring enabled in RabbitMQ using the management plugin or policy.
rabbitmqctl set_policy ha-all "^classic-queue$" '{"ha-mode":"all"}' rabbitmqadmin declare queue name=classic-queue durable=true
Quorum Queue Equivalent
This example shows how to declare a quorum queue using the RabbitMQ management CLI.
rabbitmqadmin declare queue name=quorum-queue type=quorum durable=true
When to Use Which
Choose Classic queues when you need simple, low-latency queues and can manage mirroring manually or have legacy systems that depend on them. They work well for non-critical workloads where occasional data loss is acceptable.
Choose Quorum queues when your application requires strong data consistency, automatic failover, and high availability without manual setup. They are ideal for critical messaging where data safety and fault tolerance are essential, even if it means slightly higher latency.