Low‑Latency and High‑Availability Design of RocketMQ: Evolution, Optimizations, and Capacity Planning

In the preface the authors describe the severe low‑latency challenge that the Aliware message engine faced during the Double 11 shopping festival, where slow responses, avalanche effects, and poor user experience threatened transaction volume.

The history of the message‑engine family is outlined in three generations: the first push‑based engine stored messages in a relational database, the second pull‑based engine used a proprietary storage comparable to Kafka, and the third generation, RocketMQ, combined push and pull, was open‑sourced in 2012 and has since handled trillion‑level message traffic.

The low‑latency and availability exploration covers performance metrics (throughput and latency), Little’s law, JVM pauses (GC, JIT, biased‑lock revocation) and their tuning using flags such as -XX:+PrintGCApplicationStoppedTime, lock strategies (fair vs. non‑fair, CAS‑based lock‑free paths), and memory management issues (page‑cache latency, direct reclaim, anonymous page swapping). Optimizations like memory pre‑allocation, file pre‑warming, mlock, and read‑write separation are applied.

Capacity assurance is achieved through three “magic weapons”: rate limiting (leaky‑bucket and token‑bucket algorithms), degradation (downgrade of non‑critical services), and circuit breaking (Hystrix‑style). These mechanisms protect the system from overload and prevent avalanche failures.

For high availability, RocketMQ adopts a multi‑replica Master/Slave architecture coordinated by Zookeeper. Persistent and ephemeral nodes store master‑slave state, and a stateless HA Controller observes state changes, drives the finite‑state‑machine (single‑master → async replication → semi‑sync → sync replication) and performs automatic failover within seconds.

Evaluation results show that after the optimizations, 99.995 % of write‑latency samples are under 1 ms and 100 % under 100 ms, and the system achieves five‑nine (99.999 %) availability according to MTBF/MTTR calculations.

In the outlook the team plans a fourth‑generation engine with multi‑level QoS, cross‑network/terminal/language support, and further latency reductions for emerging IoT, big‑data, and VR scenarios.

References list the cited papers and URLs.