Comprehensive Comparison of Kafka, RabbitMQ, ZeroMQ, RocketMQ, and ActiveMQ Across 17 Aspects

1. Documentation

Kafka: moderate. There is a book written by the Kafka author and some online material. RabbitMQ: abundant. Several good books and plenty of online resources. ZeroMQ: scarce. No dedicated book; most material consists of code examples and brief introductions. RocketMQ: scarce. No dedicated book; official docs are concise but lack deep technical details. ActiveMQ: abundant. No dedicated book, but many online resources.

2. Development Language

Kafka: Scala. RabbitMQ: Erlang. ZeroMQ: C. RocketMQ: Java. ActiveMQ: Java.

3. Supported Protocols

Kafka: its own TCP‑based protocol. RabbitMQ: AMQP. ZeroMQ: TCP and UDP. RocketMQ: its own protocol. ActiveMQ: OpenWire, STOMP, REST, XMPP, AMQP.

4. Message Storage

Kafka stores messages in memory, disk and databases and can accumulate large amounts. Each topic is split into partitions; partitions are distributed across brokers, with leaders and replicas balanced for load and high availability. The partitioner uses round‑robin or key‑based hashing to distribute messages.

RabbitMQ stores messages in memory and on disk, supporting limited accumulation. It distinguishes persistent and non‑persistent messages; persistent messages are written to disk and optionally kept in memory for performance, while non‑persistent messages reside only in memory unless memory pressure forces them to disk. Mirrored queues replicate messages across brokers for fault tolerance.

ZeroMQ stores messages in the sender’s memory or disk and does not support persistence.

RocketMQ stores messages on disk and supports large accumulation. It uses a CommitLog file (max 1 GB per file) for actual data and a small ConsumeQueue as an index, enabling sequential disk writes and high‑throughput performance.

ActiveMQ stores messages in memory, disk and databases, supporting limited accumulation.

5. Message Transactions

Kafka: supports transactions. RabbitMQ: supports transactions (client sets channel to transaction mode; commit succeeds only after broker acknowledges). ZeroMQ: does not support transactions. RocketMQ: supports transactions. ActiveMQ: supports transactions.

6. Load Balancing

Kafka: built‑in load balancing. Each broker (server) hosts partitions; the leader of each partition handles client requests. Consumers in a consumer group are evenly assigned partitions, and rebalancing occurs when members join or leave.

RabbitMQ: limited native load balancing. Message routing depends on exchanges and routing keys; queues are manually declared. Mirrored queues distribute master nodes across brokers, but load balancing often requires external tools such as HAProxy or LVS, or client‑side algorithms (round‑robin, weighted round‑robin, random, weighted random, source‑hash, least‑connections).

ZeroMQ: decentralized; does not provide load balancing.

RocketMQ: supports load balancing. Consumers must not exceed the number of queues; the system distributes consumers evenly across queues.

ActiveMQ: supports load balancing and can use Zookeeper for coordination.

7. Cluster Mode

Kafka: leader‑slave, stateless cluster; each broker can be both leader and follower. Partitions and replicas are spread across brokers; Zookeeper manages metadata and allows dynamic scaling.

RabbitMQ: simple clustering with a “mirrored” mode; advanced clustering is limited. Nodes can be memory‑based or disk‑based; at least one disk node is required. Queues are created on a single node, but mirrored queues replicate data for high availability.

ZeroMQ: decentralized; does not support clustering.

RocketMQ: typical master‑slave model; the open‑source version requires manual failover. NameServer is a lightweight, stateless node that stores routing information. Brokers register topics with NameServers; producers and consumers discover brokers via NameServers.

ActiveMQ: simple master‑slave clustering; advanced clustering support is limited.

8. Management Interface

Kafka: generally good. RabbitMQ: good. ZeroMQ: none. RocketMQ: none. ActiveMQ: average.

9. Availability

Kafka: very high (distributed). RabbitMQ: high (master‑slave). ZeroMQ: high. RocketMQ: very high (distributed). ActiveMQ: high (master‑slave).

10. Message Duplication Guarantees

Kafka: supports at‑least‑once and at‑most‑once semantics.

RabbitMQ: supports at‑least‑once and at‑most‑once.

ZeroMQ: only retransmission without persistence; does not fit standard delivery guarantees.

RocketMQ: supports at‑least‑once.

ActiveMQ: supports at‑least‑once.

11. Throughput (TPS)

Kafka: extremely high, thanks to batch sending and consumption.

RabbitMQ: relatively high.

ZeroMQ: extremely high.

RocketMQ: high (supports batch consumption, but not batch production).

ActiveMQ: relatively high.

12. Subscription Model and Message Dispatch

Kafka: topic‑based publish/subscribe with optional regex matching. Producers decide partition via key; consumers read from assigned partitions, with consumer‑group rebalancing.

RabbitMQ: four exchange types—direct, topic, fanout, headers. Producers declare queues and exchanges; routing key and exchange determine destination queue. Consumers pull from specific queues; messages are delivered to one consumer per queue (round‑robin when multiple consumers).

ZeroMQ: point‑to‑point (p2p).

RocketMQ: topic/messageTag based publish/subscribe with regex matching; supports both broadcast and cluster consumption.

ActiveMQ: supports both point‑to‑point (p2p) and publish/subscribe modes.

13. Ordered Messages

Kafka: supports ordering within a partition; can enforce by setting producer.max.in.flight.requests.per.connection=1.

RabbitMQ: does not support ordered delivery.

ZeroMQ: does not support ordered delivery.

RocketMQ: supports ordered messages.

ActiveMQ: does not support ordered delivery.

14. Message Acknowledgment

Kafka: supports acknowledgments (acks=0,1,all) and offset commits (auto or manual). Offsets are stored in Kafka (newer versions) rather than Zookeeper.

RabbitMQ: supports acknowledgments. Producers receive confirmation after messages are routed to all matching queues; consumers can use autoAck or manual ack. Unacknowledged messages are re‑queued if the consumer disconnects.

ZeroMQ: supports acknowledgments.

RocketMQ: supports acknowledgments.

ActiveMQ: supports acknowledgments.

15. Message Replay

Kafka: can replay by seeking a specific offset.

RabbitMQ: does not support replay.

ZeroMQ: does not support replay.

RocketMQ: can replay to a specific timestamp.

ActiveMQ: does not support replay.

16. Message Retry

Kafka: no built‑in retry, but can be implemented via offset rewind.

RabbitMQ: no built‑in retry, but can be simulated using manual acknowledgments and dead‑letter exchanges.

ZeroMQ: does not support retry.

RocketMQ: supports retry; the client retries up to three times, rotates brokers, and respects the sendMsgTimeout setting.

ActiveMQ: does not support retry.

17. Concurrency

Kafka: high concurrency; each consumer runs in its own thread, and the number of consumers must not exceed the number of partitions. Additional threads can be spawned within a consumer.

RabbitMQ: very high concurrency thanks to Erlang; each channel can be bound to a thread, and multiple threads can share a TCP connection.

ZeroMQ: high concurrency.

RocketMQ: high concurrency; similar to Kafka—consumer count must not exceed queue count, but multithreading within a consumer is possible.

ActiveMQ: high concurrency; a single broker can handle tens of thousands of messages per second, and multiple brokers can be deployed for greater throughput.