中文
devexamples
← Recipes

阅读中文版本

Adopt Quorum Queues for Durable Messaging

Replace classic mirrored queues with quorum queues to get raft-based replication, safer failover, and predictable behavior under broker restarts.

~45 minmessagingreliabilityrabbitmq

Task

Migrate a critical queue to a quorum queue and configure delivery limits and expiry.

When to use this

Mirrored queues split brain under network partitions and lose messages during failover, putting ordering and delivery guarantees at risk.

Prerequisites

  • A broker version that supports quorum queues
  • A migration window for the queue

Steps

1. Create the queue with the quorum type and choose a replication factor across distinct nodes.

Expected output: The queue replicates via raft on several nodes.

2. Set x-delivery-limit and a dead-letter target so poisoned messages do not loop forever.

Expected output: A message is redelivered a bounded number of times.

3. Update publishers and consumers to the new queue name or shovelled alias.

rabbitmqctl list_queues name type members

Expected output: Producers and consumers use the quorum queue without mirroring assumptions.

4. Verify failover by stopping a leader node and confirming the queue keeps serving.

Expected output: A leader election completes without message loss.

Troubleshooting

Problem

Throughput drops versus classic queues

Solution

Quorum queues trade some throughput for safety; add consumers or partitions rather than reverting the queue type.

Problem

Memory pressure from long queues

Solution

Apply a max-length or TTL policy; quorum queues are not designed to hold very large backlogs in memory.

Limitations

  • Quorum queues have higher write latency than classic queues and are not a drop-in for every workload.
  • They cannot be used with every feature, such as some transient or exclusive semantics.

Context

Migrate a critical queue to a quorum queue and configure delivery limits and expiry. Mirrored queues split brain under network partitions and lose messages during failover, putting ordering and delivery guarantees at risk.

Steps

  1. Create the queue with the quorum type and choose a replication factor across distinct nodes. Expected: The queue replicates via raft on several nodes.
  2. Set x-delivery-limit and a dead-letter target so poisoned messages do not loop forever. Expected: A message is redelivered a bounded number of times.
  3. Update publishers and consumers to the new queue name or shovelled alias. Expected: Producers and consumers use the quorum queue without mirroring assumptions.
  4. Verify failover by stopping a leader node and confirming the queue keeps serving. Expected: A leader election completes without message loss.
rabbitmqadmin declare queue name=orders durable=true \
  arguments='{"x-queue-type":"quorum","x-delivery-limit":5}'

Verify

  • The queue replicates via raft on several nodes.
  • A message is redelivered a bounded number of times.
  • Producers and consumers use the quorum queue without mirroring assumptions.
  • A leader election completes without message loss.

Limits

  • Quorum queues have higher write latency than classic queues and are not a drop-in for every workload.
  • They cannot be used with every feature, such as some transient or exclusive semantics.