Performance, Storage, Indexing, and Caching Design of JMQ4 Middleware

JMQ is a message middleware developed by JD's middleware team, launched in 2014 and serving nearly ten thousand applications, with peak traffic exceeding 5 × 10¹² messages during the 2018 11.11 shopping festival.

In 2018, JMQ4 achieved a major performance boost, reaching over 1 million TPS per broker, and the article compares its write throughput against JMQ2 and Kafka in two typical scenarios: single‑message synchronous flush and batch asynchronous flush.

In the synchronous scenario, JMQ4 writes about 230 k messages per second, roughly twice JMQ2 and more than double Kafka's 92 k TPS. In the batch asynchronous scenario, JMQ4 reaches 1.037 million TPS, ten times its predecessor, while Kafka peaks at 1.14 million TPS.

The storage design of JMQ4 inherits concepts from JMQ2 and Kafka but adopts a hybrid approach: each topic has its own log files, and each partition maintains a set of fixed‑length dense indexes, enabling direct calculation of index positions and fast message lookup.

Unlike Kafka's sparse index, JMQ’s dense fixed‑length index allows O(1) index location computation, simplifying retrieval.

For high‑performance I/O, JMQ4 uses Java DirectBuffer combined with asynchronous FileChannel writes, which outperforms MappedByteBuffer despite an extra memory copy, due to reduced page‑fault overhead and better control of batch sizes.

The caching subsystem maps each message file to a DirectBuffer page, exploits the append‑only and hot‑tail characteristics of log data, and employs a two‑dimensional eviction policy that prefers removing cold pages far from the log tail, thereby avoiding cache pollution.

Additionally, JMQ4 predicts sequential access patterns to pre‑load the next cache page asynchronously, further improving cache hit rates for typical read‑write workloads.