Why Kafka Outperforms RocketMQ: A Deep Dive into Zero‑Copy and Architecture

In a previous article we introduced RocketMQ’s architecture, which borrows ideas from Kafka but adds its own adjustments. Despite these similarities, Kafka remains unbeaten in performance.

Alibaba’s middleware team benchmarked both systems under identical conditions and found Kafka to be roughly 50% faster in throughput, though RocketMQ can still handle on the order of 100,000 messages per second.

What Is Zero‑Copy?

Message queues store messages on disk to avoid loss on process crashes. When sending a message from disk to a consumer, the data typically moves through several copies between user space and kernel space.

Message Sending Process

The operating system separates user space and kernel space. A program in user space must invoke system calls to interact with hardware.

Program calls read() → disk data is copied from the device to a kernel‑space buffer.

The kernel buffer is then copied to user space.

Program calls write() → data is copied from user space to the socket’s send buffer.

Data is finally copied from the socket buffer to the NIC.

This flow involves two system calls and four user‑kernel transitions, resulting in four data copies.

mmap Zero‑Copy

mmap

maps a kernel buffer directly into user space, eliminating the copy between kernel and user space for that step.

Disk data is copied from the device to a kernel buffer.

The kernel buffer is mapped into user space without an additional copy.

Program calls write() → data is copied from the kernel buffer to the socket buffer, then to the NIC.

The overall process now uses two system calls, four user‑kernel switches, and three data copies—saving one copy compared with the naïve approach.

sendfile Zero‑Copy

sendfile

lets the kernel transfer data from a file descriptor directly to a socket, bypassing user space entirely.

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

Disk data is copied from the device to a kernel buffer.

The kernel buffer is copied directly to the NIC without any user‑space involvement.

This reduces the operation to one system call, two user‑kernel switches, and only two data copies, achieving higher throughput.

Kafka adopts sendfile, gaining fewer copies and kernel switches, which explains its superior performance. RocketMQ uses mmap, which still incurs an extra copy but preserves access to the message content in user space.

RocketMQ needs the message payload for features such as message filtering, replay, transactional support, delayed queues, and dead‑letter handling. If it used sendfile, the application layer would not see the message bytes, making these features impossible. Kafka, focused on raw throughput, can afford to lose that visibility.

Choosing Kafka or RocketMQ

Selection depends on the scenario. For big‑data pipelines that frequently involve Spark or Flink, Kafka’s high throughput is advantageous. In environments where richer messaging capabilities (e.g., DLQ, transaction, filtering) are required and the component stack supports it, RocketMQ is a better fit.

Summary

RocketMQ simplifies coordination nodes and partition/replication models but adds features like message filtering, replay, transactions, delayed and dead‑letter queues.

Kafka’s architecture uses the sendfile zero‑copy path, resulting in fewer copies and higher performance.

RocketMQ sacrifices some throughput to retain message content for advanced functionalities.