An Introduction to Apache RocketMQ: Concepts, Architecture, Message Types, and Best Practices

RocketMQ Introduction

Apache RocketMQ is a low‑latency, high‑concurrency, highly available and reliable distributed messaging middleware. It provides asynchronous decoupling and peak‑shaving capabilities for distributed applications, and supports massive message accumulation, high throughput and reliable retry.

RocketMQ Concepts

Topic : a message category that groups related messages, e.g., an order topic for all order‑related messages.

Producer : the component that creates and sends messages to a Topic.

Consumer : the component that receives and processes messages from a Topic.

Message : the payload sent by a producer and consumed by a consumer.

Message Attributes : custom business‑related properties such as Message Key and Tag.

Group : a set of producers or consumers that share the same publishing or subscription logic.

Why Use RocketMQ?

Asynchronous Decoupling

As micro‑service architectures grow, asynchronous decoupling reduces coupling between services and improves throughput. The article illustrates an e‑commerce order flow and shows how asynchronous processing can shorten the critical path for payment callbacks.

In the synchronous flow, steps 3‑5 block the user; in the asynchronous flow those steps are handled in the background, speeding up the callback.

Peak‑Shaving

RocketMQ can absorb traffic spikes, such as flash‑sale bursts, protecting system stability and enhancing user experience, provided the business logic can be processed asynchronously.

Distributed Transaction Final Consistency

Message‑based final‑consistency is a common pattern for distributed transactions, and RocketMQ’s transaction messages help ensure data consistency across services.

Data Distribution

RocketMQ can distribute raw data to multiple downstream systems (e.g., Elasticsearch, Redis) and can also forward MySQL binlog events using ordered messages to maintain consistency.

RocketMQ Architecture

NameServer : a lightweight, stateless node that provides service discovery for Brokers.

Broker : stores and forwards messages; consists of Master and Slave Brokers.

Producer : maintains long‑lived connections to NameServer and Master Broker, sending heartbeats.

Consumer : connects to NameServer to obtain routing info and subscribes to Master/Slave Brokers, also sending heartbeats.

RocketMQ Message Types

RocketMQ supports several message types to meet different scenarios.

Ordinary Message

Basic messages without special features. They can be sent synchronously, asynchronously, or one‑way.

Synchronous Send

The producer waits for a server response before proceeding.

Asynchronous Send

The producer does not wait for a response and can handle callbacks.

One‑Way Send

The producer sends the message without caring about the result, offering high throughput but risking loss.

Ordered Message

Ensures that messages are consumed in the same order they were produced, which is critical for scenarios like MySQL binlog replication.

Scheduled (Delayed) Message

Messages are delivered to consumers at a specified future time or after a delay, useful for order timeout cancellation.

Transaction Message

Provides XA‑like two‑phase commit semantics to achieve eventual consistency across distributed services.

Producer sends a half‑transaction message.

Broker persists the message and returns an ACK.

Producer executes local transaction.

Producer commits or rolls back the message based on local transaction outcome.

If no second‑phase confirmation, the broker will later query the producer.

Producer responds to the query and the broker finalizes the message.

Best Practices

Message Retry

RocketMQ retries failed deliveries up to 16 times by default; consumers must ACK only after local business succeeds.

Message Filtering

Tags can be used to filter messages on the broker side so consumers receive only relevant types.

Consumption Modes

Two modes: Cluster consumption (only one instance in a group processes a message) and Broadcast consumption (every instance processes the message).

Idempotent Consumption

RocketMQ’s Exactly‑Once delivery semantics help achieve idempotency; using a business‑level unique MessageKey is recommended.

Local Transaction Message Pattern

This section describes the local transaction table approach where messages are first stored in a database table within the same transaction as business logic, then a separate process publishes them to RocketMQ.

Reference Code

The author mentions that related code can be obtained via WeChat search “猿天地” with keyword “kitty”.

About the Author

Yin Jihuan, a technology enthusiast and author of “Spring Cloud Microservices – Full‑Stack Technology and Case Analysis”.