Why Is RocketMQ So Fast? 10 Core Techniques Explained

Hello everyone, I am Su San.

RocketMQ, Alibaba's open‑source message middleware, is loved by many developers because it processes and pulls messages extremely fast.

Why is RocketMQ so fast? The following ten aspects explain the reasons.

Batch Sending Messages

RocketMQ supports sending multiple messages in a single batch. Example code:

public class Producer {
    public static void main(String[] args) throws Exception {
        // Create a producer with group "sanyouProducer"
        DefaultMQProducer producer = new DefaultMQProducer("sanyouProducer");
        // Set NameServer address
        producer.setNamesrvAddr("192.168.200.143:9876");
        // Start the producer
        producer.start();

        // Use a list to hold multiple messages
        List<Message> messages = new ArrayList<>();
        messages.add(new Message("sanyouTopic", "三友的java日记 0".getBytes()));
        messages.add(new Message("sanyouTopic", "三友的java日记 1".getBytes()));
        messages.add(new Message("sanyouTopic", "三友的java日记 2".getBytes()));
        // Send the batch and print the result
        SendResult sendResult = producer.send(messages);
        System.out.printf("%s%n", sendResult);

        // Shut down the producer
        producer.shutdown();
    }
}

Batch sending reduces the number of network communications between the client and the broker, improving transmission efficiency.

When using batch messages, note three points:

All messages in the batch must have the same Topic.

Delay messages and transactional messages are not supported.

The total size of a batch (including ordinary messages) cannot exceed 4 MB by default.

Message Compression

If a message exceeds 4 KB, RocketMQ compresses it to reduce bandwidth pressure and storage space.

Batch messages are not compressed.

Compressed messages are stored on disk without being decompressed; consumers receive compressed messages and decompress them locally.

High‑Performance Network Communication Model

RocketMQ uses Netty, a powerful asynchronous, event‑driven network framework, to achieve high throughput and low latency.

Netty’s advantages include asynchronous I/O, zero‑copy buffers, extensibility, simplified API, built‑in SSL/TLS support, and rich protocol implementations.

Zero‑Copy Technology

To persist messages, RocketMQ writes them to disk. Traditional I/O involves multiple context switches and data copies between user space, kernel space, and the network stack.

Zero‑copy reduces these copies. Two common methods are mmap() and sendfile() .

mmap()

mmap maps a file directly into the process’s address space, allowing the application to read/write the file as if it were memory, eliminating one CPU copy.

FileChannel fileChannel = new RandomAccessFile("test.txt", "rw").getChannel();
MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, fileChannel.size());

RocketMQ uses mmap for efficient file I/O.

sendfile()

sendfile transfers data from a file descriptor directly to a socket, reducing both CPU copies and context switches.

FileChannel channel = FileChannel.open(Paths.get("./test.txt"), StandardOpenOption.WRITE, StandardOpenOption.CREATE);
// Transfer data to the target buffer
channel.transferTo(position, len, target);

Java NIO’s FileChannel.transferTo is based on sendfile.

Sequential Write

RocketMQ writes messages sequentially to disk, reducing disk head movement and seek time, which speeds up large‑scale writes.

Efficient Data Storage Structure

Topic and Queue Relationship

Each Topic creates four queues per broker by default; each queue is identified by a sequential queueId.

CommitLog

Messages are persisted in files called CommitLog, split into 1 GB segments. Each entry stores the message body plus metadata such as Topic, queueId, producer IP, etc.

ConsumeQueue

For each queue, RocketMQ maintains a ConsumeQueue file that stores 20‑byte index entries (offset in CommitLog, message length, tag hash). This acts as an index for fast message lookup.

Consumers specify Topic, queueId, offset, and batch size; the broker uses ConsumeQueue to locate the corresponding messages in CommitLog in O(1) time.

Asynchronous Processing

Async Flush

Messages are first written to the kernel page cache; a background thread flushes them to disk every 0.5 seconds, ensuring durability without blocking the producer.

Async Master‑Slave Replication

In a master‑slave cluster, the master writes to its CommitLog and an asynchronous thread pushes the data to the slave, which writes it to its own CommitLog.

Batch Processing

Consumers can pull multiple messages in one request, and the broker batches offset commits (default every 5 seconds), reducing network overhead.

Lock Optimization

RocketMQ uses ReentrantLock for write serialization and provides a CAS‑based lock for low‑contention scenarios. It also relies heavily on atomic classes such as AtomicInteger and AtomicLong to avoid explicit locks.

Thread‑Pool Isolation

Different request types (e.g., message storage vs. message fetching) are handled by separate thread pools, preventing one slow workload from affecting another and improving overall concurrency.

Summary

The ten aspects above—batch sending, compression, Netty networking, zero‑copy I/O, sequential writes, optimized storage structures, asynchronous flush and replication, batch processing, lock optimizations, and thread‑pool isolation—collectively give RocketMQ its outstanding performance. Additional optimizations such as long‑poll pulling and file pre‑warming further enhance speed.