Unveiling RocketMQ: From History to Deep Dive into Architecture and Source Code

1. RocketMQ Development History

In 2007 Alibaba launched the "Five‑Color Stone" project, creating the first generation message engine Notify. By 2010 the B2B team built Napoli based on ActiveMQ 5.1. In 2011, after studying Kafka, Alibaba rewrote it in Java as MetaQ 1.0 to address ordered messages and massive backlog. MetaQ 2.0 appeared in 2012, but scaling issues led to RocketMQ 3.0 (internally MetaQ 3.0). RocketMQ later powered Aliware MQ and Notify 3.0, and its core was donated to Apache in 2016.

The internal Alibaba ecosystem built three products around the RocketMQ kernel: MetaQ (pull model for ordered and bulk messages), Notify (push model for transactional messages), and Aliware MQ (commercial cloud offering).

2. RocketMQ Principles and Architecture

The overall deployment includes NameServer (stateless discovery), Broker‑Master, Broker‑Slave, Producer, and Consumer. Communication flow:

NameServer registers brokers and periodically updates topic routing.

Producer fetches routing from local cache or pulls from NameServer, selects a MessageQueue, and sends the message.

Broker receives the message and persists it to disk.

The network module rocketmq‑remoting underpins all inter‑process communication, built on Netty.

3. Source Code Directory Overview (RocketMQ 4.4.0, Netty 4.0.42.Final)

rocketmq‑broker

: core broker handling producer/consumer requests and storage. rocketmq‑client: Java client implementation (C++/Go are community contributions). rocketmq‑common: shared utilities, constants, and configs. rocketmq‑example: sample code for ordered messages, push/pull consumers. rocketmq‑filter: message filtering service. rocketmq‑namesrv: name service for broker discovery. rocketmq‑remoting: Netty‑based communication layer. rocketmq‑srvutil: command‑line utilities. rocketmq‑store: storage implementation, including index service and HA. rocketmq‑tools: management utilities.

4. Service Startup

The entry class org.apache.rocketmq.broker.BrokerController initializes thread pools for sending, consuming, and cleaning expired requests, then starts the broker.

5. Client Message Flow

Producer uses MQProducer to send messages asynchronously. The call chain is: sendKernelImpl →

MQClientAPIImpl.sendMessage

sendMessage

decides sync/async and calls

sendMessageAsync

sendMessageAsync

invokes RemotingClient.invokeAsync (implemented by NettyRemotingClient).

6. Remoting Communication Layer

The remoting module consists of classes such as NettyRemotingClient, NettyRemotingAbstract, and internal services for async invoke. After writing to the channel, Netty’s selector triggers broker‑side processing.

7. Broker Processing

Incoming messages reach org.apache.rocketmq.broker.processor.SendMessageProcessor, which calls sendMessage. This ultimately invokes MessageStore.putMessage (implemented by DefaultMessageStore).

8. Store Layer

The store handles six file types: large files (Index, ConsumeQueue, CommitLog) and small files (Checkpoint, config, abort). Large files use MappedByteBuffer via the MappedFile wrapper for high‑performance random reads and sequential writes. Messages are appended through MappedFile.appendMessagesInner, which delegates to DefaultAppendMessageCallback.doAppend to serialize data into the buffer and update metrics.

9. Flush Mechanisms

Three flush strategies exist:

Real‑time flush (default): FlushRealTimeService runs every 500 ms, flushing at least four pages or after a 10 s thorough interval.

Commit‑real‑time service (used when transientStorePoolEnable=true): writes to an in‑memory buffer, then commits to FileChannel at configurable intervals.

Non‑real‑time flush: thread sleeps or waits for a wake‑up signal before invoking MappedFileQueue.flush, which ultimately calls MappedByteBuffer.force().

10. HA Synchronization

Two replication modes:

SYNC_MASTER : master writes to disk, then waits for slave acknowledgment via GroupTransferService.

ASYNC_MASTER : master returns success after local write; slave sync occurs asynchronously, offering higher throughput when strong consistency is not required.

11. Transactional Messages

RocketMQ provides three producer types: NormalProducer, OrderProducer, and TransactionProducer. Transactional messaging follows a two‑phase commit:

Producer sends a prepare message (invisible to consumers).

Local transaction executes.

If the local transaction succeeds, the producer sends a commit command; otherwise, it sends a rollback command.

If the broker does not receive a commit/rollback within a timeout, it performs a transaction status check (callback) to the producer.

The relevant source resides under broker.transaction. Note that after version 3.2.6 the transaction check API was removed from the open‑source release, requiring users to implement their own callbacks.

Summary : RocketMQ’s architecture combines a lightweight discovery service, a Netty‑based remoting layer, and a highly optimized storage subsystem that leverages memory‑mapped files and configurable flush/HA strategies. Understanding the startup sequence, client‑to‑broker communication, and transaction workflow is essential for tuning performance and ensuring reliability in large‑scale distributed systems.