Home/Learn/RabbitMQ/High Availability

High Availability

Advanced
Operations

Use quorum queues for replicated durability in clusters; deploy behind a load balancer; use multiple nodes to tolerate single-node failures without message loss.

Overview

RabbitMQ high availability relies on clustering (multiple broker nodes sharing metadata) combined with replicated queue types. Classic mirrored queues (deprecated in 3.x) are replaced by Quorum Queues — Raft-based replicated queues that guarantee durability and consistency under node failures. A three-node cluster tolerates one node failure. Clients connect via a load balancer (HAProxy, AWS NLB) or use a list of broker addresses and the automatic reconnection API. Stream queues offer an additional option for high-throughput, append-only scenarios.

Cluster Setup & Quorum Queues

A RabbitMQ cluster shares exchange and binding metadata across nodes. Quorum queues replicate message data using Raft consensus. Declare a quorum queue with x-queue-type=quorum; set x-quorum-initial-group-size for the replica count.

Shell + Java — cluster join and quorum queue
# Join nodes to a cluster (on node 2 and 3)
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app

# Verify cluster status
rabbitmqctl cluster_status

# Declare a quorum queue (AMQP 0-9-1 args)
@Bean
public Queue orderQueue() {
    return QueueBuilder.durable("orders.processing")
        .quorum()                                // x-queue-type=quorum
        .withArgument("x-quorum-initial-group-size", 3)  // 3 replicas
        .build();
}

// Quorum queue policy via rabbitmqctl
rabbitmqctl set_policy quorum-all ".*" \
  '{"x-queue-type":"quorum","x-quorum-initial-group-size":3}' \
  --apply-to queues

Load Balancer & Client Reconnection

Deploy an HAProxy or AWS NLB in front of broker nodes. Configure Spring AMQP with multiple addresses and enable automatic connection recovery so clients reconnect transparently after node failures.

HAProxy + Properties — load balancer config
# HAProxy configuration for RabbitMQ AMQP (port 5672)
frontend rabbitmq_front
    bind *:5672
    default_backend rabbitmq_back

backend rabbitmq_back
    balance roundrobin
    option tcp-check
    server rabbit1 10.0.0.1:5672 check inter 5s
    server rabbit2 10.0.0.2:5672 check inter 5s
    server rabbit3 10.0.0.3:5672 check inter 5s

# Spring Boot application.properties — multiple broker addresses
spring.rabbitmq.addresses=10.0.0.1:5672,10.0.0.2:5672,10.0.0.3:5672
spring.rabbitmq.connection-timeout=5000

# Or use address-shuffle-mode=random for client-side load spreading
spring.rabbitmq.address-shuffle-mode=random

Automatic Recovery & Publisher Confirms

Spring AMQP enables automatic connection and topology recovery by default. Combine with publisher confirms (or transactions) to detect and handle messages lost during a broker failover.

Java — connection recovery + publisher confirms
@Configuration
public class RabbitConfig {

    @Bean
    public CachingConnectionFactory connectionFactory() {
        CachingConnectionFactory factory = new CachingConnectionFactory();
        factory.setAddresses("rabbit1:5672,rabbit2:5672,rabbit3:5672");
        // Automatic recovery is ON by default in the underlying amqp-client
        factory.getRabbitConnectionFactory()
               .setAutomaticRecoveryEnabled(true);
        factory.getRabbitConnectionFactory()
               .setNetworkRecoveryInterval(5_000);

        // Enable publisher confirms for durability guarantee
        factory.setPublisherConfirmType(
            CachingConnectionFactory.ConfirmType.CORRELATED);
        return factory;
    }

    @Bean
    public RabbitTemplate rabbitTemplate(CachingConnectionFactory cf) {
        RabbitTemplate template = new RabbitTemplate(cf);
        template.setConfirmCallback((correlationData, ack, cause) -> {
            if (!ack) {
                log.error("Message NOT confirmed — cause: {}", cause);
                // re-queue or dead-letter the message
            }
        });
        return template;
    }
}

Key Points to Remember

  • 1Quorum Queues (Raft-based) replace Classic Mirrored Queues for HA — more reliable and consistent.
  • 2A 3-node cluster tolerates 1 node failure; a 5-node cluster tolerates 2.
  • 3Deploy HAProxy or AWS NLB in front of brokers; configure Spring AMQP with all broker addresses.
  • 4Automatic connection recovery in amqp-client reconnects transparently after broker failover.
  • 5Publisher confirms detect messages lost during failover — use CORRELATED confirm mode.
  • 6Quorum queues require durable=true; they do not support non-durable or exclusive queues.

Interview Questions

Sign in to ask Aria
1

What is the difference between classic mirrored queues and quorum queues?

MediumRevolut
2

How many nodes does a RabbitMQ quorum queue need to tolerate one node failure?

EasyPivotal
3

How does publisher confirm mode work and when should you use it?

MediumAmazon
4

What happens to consumers during a RabbitMQ node failure if automatic recovery is enabled?

HardNetflix
5

How would you configure Spring AMQP to connect to a RabbitMQ cluster?

MediumInfosys

Ask Aria about High Availability

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Sign in to save personal notes for this topic.

Discussion

Sign in to join the discussion.

Loading discussion…