From ActiveMQ to RocketMQ: My Journey Through Message Queues and Lessons Learned

1 Initial Encounter with ActiveMQ

1.1 Asynchrony & Decoupling

In 2011, while developing a user‑center system for an online lottery company, the author combined user registration and SMS sending into a single module, leading to slow response times and tight coupling with the SMS channel.

Introducing a message queue allowed the SMS function to be split into an independent job service; the user‑center would publish a message after registration, and the job service would consume it to send the SMS, achieving asynchronous processing and decoupling.

1.2 Scheduler Center

The lottery system’s complex order lifecycle required a scheduler center to maintain core state machines, prize‑distribution processes, and data generation, communicating with other services via a message queue.

1.3 Restart Strategy

When daily message volume surged to 1.5‑2 million, the scheduler center could not consume messages, causing repeated hangs. The team resorted to repeatedly restarting the service, eventually identifying large Oracle transactions as the root cause.

Solutions included splitting oversized messages into batches and configuring the datasource to abort transactions exceeding a time threshold.

1.4 Retrospective

ActiveMQ’s Spring API proved simple, but high‑throughput scenarios revealed issues such as message pile‑up causing hangs and limited high‑availability mechanisms (master/slave mode requiring manual failover).

High throughput can lead to message accumulation and service hangs.

Master/slave deployment lacks automatic failover.

Occasional message loss where producers see success but only slaves can query the message.

2 Advancing with Redis & RabbitMQ

2.1 Can Redis Be a Message Queue?

At a hotel coupon system, Storm consumed data from a Redis list acting as a push/pop queue, processing millions of records daily. While functional, concerns included potential message loss, memory pressure, and the need for monitoring.

Redis‑based queues are suitable when small‑probability loss is tolerable, accumulation risk is low, and consumer logic is simple.

2.2 RabbitMQ Is a Pipe, Not a Pool

RabbitMQ, built with Erlang, provided high availability via mirrored queues and handled millions of messages per day in a coupon system. However, under heavy load the queue’s performance degraded sharply, leading to message backlog.

Testing with 1 000 000 00 messages revealed that when consumer speed lagged, the queue accumulated over 5 million messages, causing latency spikes.

3 Elevating with MetaQ

MetaQ originated from an open‑source MQ project on LinkedIn and later migrated to Apache Kafka; it uses a pull‑based model and Zookeeper for service discovery and offset storage.

3.1 Consumer Models

MetaQ supports cluster consumption and broadcast consumption. In a ride‑hailing order system, a message sent to MetaQ can be consumed by both the dispatch service and the BI service (cluster consumption), while driver push notifications use broadcast consumption.

3.2 Aggressive Smoothing

To handle order spikes, the team cached order modifications, sent a message to MetaQ, and let a persistence service verify and store the order, reducing database pressure.

3.3 Message SDK Encapsulation

The team wrapped MetaQ client APIs into a unified SDK, exposing only Topic and Group to developers, handling environment‑specific NameServer resolution, and supporting hot‑config updates without client restarts.

3.4 Refactoring MetaQ

Issues such as occasional RPC hangs and weak operational tooling prompted a migration to a dedicated Zookeeper cluster and replacement of the Gecko network layer with Netty.

4 Falling in Love with RocketMQ

4.1 The Open‑Source Feast

After joining the RocketMQ community, the author built a toy RPC using RocketMQ’s Netty‑based remoting layer, later applying the knowledge to a SMS service where messages are sent to a queue and workers consume them to call various providers.

The SMS service’s dashboard allowed monitoring of send records and configuration of channel providers.

4.2 Kafka: The Big‑Data Backbone

Kafka provides high‑throughput, durable, horizontally scalable streaming, widely used for log aggregation, real‑time analytics, and as a data hub connecting systems like HBase, Elasticsearch, and Spark.

4.3 How to Choose a Message Queue

When evaluating MQ solutions, consider the specific scenario, team’s technical expertise, operational costs, and organizational factors. The author notes the rapid emergence of QMQ, TubeMQ, Pulsar, and stresses that technology selection must balance readiness, cost, and human factors.

5 Final Thoughts

“There is no such thing as a random breakthrough; it comes from accumulated thinking and practice.” – paraphrased from a speech.

The author reflects that learning message queues is a continuous process of curiosity, practice, and incremental improvement, encouraging readers to keep learning a little each day.