Kafka vs RabbitMQ vs ZeroMQ vs RocketMQ vs ActiveMQ: 17‑Point Comparison

Documentation

Kafka: Medium amount of material; official book by the author and some online resources.

RabbitMQ: Abundant documentation; several good books and many online articles.

ZeroMQ: Limited material; few dedicated books, most resources are code examples and brief introductions.

RocketMQ: Limited material; two books exist, official docs are concise and lack deep technical details.

ActiveMQ: Plenty of material; many online resources but no dedicated book.

Development Language

Kafka: Scala

RabbitMQ: Erlang

ZeroMQ: C

RocketMQ: Java

ActiveMQ: Java

Supported Protocols

Kafka: Proprietary protocol based on TCP.

RabbitMQ: AMQP

ZeroMQ: TCP, UDP

RocketMQ: Proprietary protocol.

ActiveMQ: OpenWire, STOMP, REST, XMPP, AMQP

Message Storage

Kafka: Stores messages in partitions across multiple brokers. Each partition is a log segment on disk; replicas are distributed for load‑balancing and high availability. Supports massive accumulation; can use in‑memory, disk, or database as needed.

RabbitMQ: Supports persistent and non‑persistent messages. Persistent messages are written to disk and optionally cached in memory; non‑persistent messages reside in memory and may be swapped to disk under pressure. Mirrored queues replicate data across brokers for HA.

ZeroMQ: No built‑in persistence; messages exist only in sender’s memory or optional disk buffer.

RocketMQ: Disk‑based storage using a commitLog (1 GB per file) and a lightweight ConsumeQueue index. CommitLog holds the raw payload; ConsumeQueue stores offset, size, and tagcode for fast lookup. Supports large accumulation with sequential writes.

ActiveMQ: Supports in‑memory, disk, and database storage; limited accumulation compared with Kafka and RocketMQ.

Transaction Support

Kafka: Transactions are supported via the producer API.

RabbitMQ: Transactions are supported by setting the channel to transaction mode; this reduces throughput.

ZeroMQ: Not supported.

RocketMQ: Supported.

ActiveMQ: Supported.

Load Balancing

Kafka: Built‑in load balancing through partition leaders and consumer‑group rebalancing. Partitions are automatically distributed across brokers; consumers in a group share partitions evenly.

RabbitMQ: Native load balancing is limited. Routing is determined by exchanges and routing keys; manual configuration or external load balancers (HAProxy, LVS) are required for better distribution.

ZeroMQ: Decentralized; does not provide load‑balancing mechanisms.

RocketMQ: Supports load balancing; brokers are master/slave and NameServer maintains routing information. Consumer count should not exceed queue count.

ActiveMQ: Load balancing can be achieved with ZooKeeper‑based clustering.

Cluster Mode

Kafka: Stateless leader‑slave cluster; each broker can be leader or follower. Relies on ZooKeeper for membership, topic metadata, and dynamic scaling.

RabbitMQ: Simple master‑slave replication; queues are created on a single node. Advanced clustering features are limited.

ZeroMQ: No clustering; pure peer‑to‑peer.

RocketMQ: Master‑slave model with a stateless NameServer. Brokers register topics with NameServer; producers/consumers discover brokers via NameServer.

ActiveMQ: Simple master‑slave clustering; advanced clustering is not well supported.

Management UI

Kafka: Basic UI (e.g., Kafka Manager, Confluent Control Center).

RabbitMQ: Rich web UI for monitoring queues, exchanges, and connections.

ZeroMQ: None.

RocketMQ: Separate management console must be started as an external service.

ActiveMQ: Basic UI.

Availability

Kafka: Very high due to distributed architecture and replication.

RabbitMQ: High with master‑slave mirroring.

ZeroMQ: High (depends on application design).

RocketMQ: Very high; distributed with master‑slave replication.

ActiveMQ: High with master‑slave setup.

Message Duplication Guarantees

Kafka: Supports at‑least‑once and at‑most‑once delivery.

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

ZeroMQ: Only retransmission; no persistence, so standard guarantees do not apply.

RocketMQ: Supports at‑least‑once.

ActiveMQ: Supports at‑least‑once.

Throughput (TPS)

Kafka: Very high; batch send/consume reduces per‑message overhead.

RabbitMQ: Relatively high; performance depends on persistence and routing.

ZeroMQ: Very high; minimal protocol overhead.

RocketMQ: High; batch consumption is supported.

ActiveMQ: Relatively high; single broker can handle >10 k msgs/s, scaling with more brokers.

Subscription Model & Message Distribution

Kafka: Topic‑based pub/sub with optional regex matching. Consumer groups provide load‑balanced consumption; each partition is consumed by only one consumer within a group.

RabbitMQ: Four exchange types (direct, topic, headers, fanout). Queues are basic storage units; messages are routed based on exchange and routing key, then delivered round‑robin to consumers.

ZeroMQ: Point‑to‑point (p2p) sockets; no built‑in pub/sub.

RocketMQ: Topic/messageTag based pub/sub. Supports both broadcast (multiple consumers receive the same message) and cluster consumption (messages are load‑balanced across consumers).

ActiveMQ: Supports both point‑to‑point and pub/sub modes.

Ordered Messages

Kafka: Ordering guaranteed per partition. Set max.in.flight.requests.per.connection=1 to preserve order during retries.

RabbitMQ: No strict ordering guarantee.

ZeroMQ: No ordering guarantee.

RocketMQ: Supports ordered consumption per queue.

ActiveMQ: No ordering guarantee.

Message Acknowledgement

Kafka: Producer acks (0, 1, all). Consumers can commit offsets automatically or manually.

RabbitMQ: Publisher confirms and consumer acknowledgements (autoAck true/false). Unacknowledged messages are re‑queued.

ZeroMQ: Basic send/receive semantics; no explicit ack mechanism.

RocketMQ: Supports acknowledgements for both producers and consumers.

ActiveMQ: Supports acknowledgements.

Message Replay

Kafka: Consumers can seek to a specific offset to reprocess messages.

RabbitMQ: Not supported.

ZeroMQ: Not supported.

RocketMQ: Can replay messages from a specific timestamp.

ActiveMQ: Not supported.

Message Retry

Kafka: No built‑in retry; can be implemented by rewinding offsets.

RabbitMQ: No built‑in retry; can be achieved with manual acknowledgements and re‑queueing.

ZeroMQ: Not supported.

RocketMQ: Internal retry up to three times with broker rotation and configurable timeout.

ActiveMQ: Not supported.

Concurrency

Kafka: High concurrency; number of consumers limited by partition count. Multi‑threaded consumers can increase parallelism.

RabbitMQ: Extremely high concurrency; Erlang VM allows many channels per connection. basicQos can limit unacknowledged messages per consumer.

ZeroMQ: High concurrency; sockets are thread‑safe.

RocketMQ: High concurrency; consumer count limited by queue count. Thread pool size adjustable via consumeThreadMin and consumeThreadMax.

ActiveMQ: High concurrency; a single broker can handle >10 k msgs/s, scaling linearly with additional brokers.