How Do RabbitMQ, Kafka, and RocketMQ Achieve High Availability?

From a high‑availability perspective, this article examines RabbitMQ, Kafka, and RocketMQ, outlining their design approaches.

1. RabbitMQ

RabbitMQ offers three deployment modes: single‑node, classic cluster, and mirrored cluster.

Single‑node mode is unrelated to high availability, so we focus on the two cluster modes.

1.1 Classic Cluster Mode

In a classic cluster, a queue resides on a single broker; brokers synchronize metadata but not the queue’s messages. If that broker fails, the queue becomes unavailable and, without message persistence, messages are lost. This mode provides good scalability but not high availability.

1.2 Mirrored Cluster Mode

Mirrored mode replicates both metadata and messages of a queue to other brokers, achieving full backup. If a broker fails, other brokers continue serving the queue without data loss, thus providing high availability at the cost of reduced scalability, as queue capacity is limited by a single broker.

Classic cluster – no high availability, better scalability.

Mirrored cluster – high availability, poorer scalability.

2. Kafka

Kafka partitions a topic into multiple partitions; the topic is a logical concept while partitions store the actual data. Partitions are distributed across brokers, allowing the topic to scale by adding more partitions.

Each partition can have multiple replicas on different brokers, providing high availability. When a broker fails, its partitions become unavailable, but replicas on other brokers take over.

Replicas have two roles: Leader and Follower. The leader, elected by Kafka, handles reads and writes and synchronizes new messages to followers. Followers act as candidates; if the leader fails, a follower is elected as the new leader.

Write acknowledgment can be configured as:

Write to leader only – fast but possible message loss if the leader fails before replication.

Write after all followers have synced – highly reliable but slower.

3. RocketMQ

RocketMQ consists of a NameServer cluster (metadata) and a Broker cluster (queue data), both requiring high availability.

NameServers run independently; multiple instances synchronize full metadata so that as long as one NameServer is alive, the cluster operates.

Broker deployment options include:

Multiple Masters – data is spread across masters; a single master failure makes its data unavailable.

Multiple Masters with Slaves – each master replicates to a slave; if a master fails, the slave takes over after a brief pause.

Dledger Group – a master with two slaves forms a Dledger group, enabling automatic master election and seamless failover.

Data synchronization can be asynchronous (fast, possible loss) or synchronous (no loss, slower).

In summary, RabbitMQ, Kafka, and RocketMQ each adopt different strategies to balance scalability and high availability.