RocketMQ Overview & Common Scenarios

RocketMQ is a distributed message queue (Alibaba open source): topics, tags, producer/consumer groups, and features like delay messages, order messages, and transactions. This article gives a high-level overview and when to use it (e.g. order, delay, broadcast) with a short comparison to Kafka.

Overview

• Topics and tags: Messages belong to a topic; optional tags (e.g. order_create, order_pay) allow consumers to filter by tag. One topic can serve multiple logical event types.
• Producer / Consumer group: Producers send to a topic; consumers in a group share consumption (each queue is consumed by one consumer in the group). Similar to Kafka’s consumer group.
• Ordered message: Messages with the same message group (sharding key) are sent to the same queue and consumed in order. Use for order-by-entity semantics (like Kafka’s partition by key).
• Delay message: Message can be delivered after a fixed delay (e.g. 30s, 1m). Use for delayed tasks (e.g. order timeout cancel, reminder).

Example

Example 1: Send and consume by tag

JavaCopy
// Producer: topic + tag
Message msg = new Message("OrderTopic", "order_create", orderId, body);
producer.send(msg);

// Consumer: subscribe with tag filter
consumer.subscribe("OrderTopic", "order_create || order_pay");

• Consumer receives only messages whose tag matches the filter. Reduces unnecessary processing when one topic has multiple event types.

Example 2: Ordered message (same queue for same key)

JavaCopy
// Same orderId → same queue → order preserved
SendResult r = producer.send(msg, (m, o) -> {
    return orderId.hashCode() % queueCount;  // or use MessageQueueSelector by orderId
}, orderId);

• Use for scenarios that require order per entity (e.g. order state machine, balance updates per account).

Example 3: Delay message

JavaCopy
msg.setDelayTimeLevel(3);  // e.g. 10s delay (level 3)
producer.send(msg);

• Message is stored and delivered after the configured delay. Typical use: order timeout cancellation (send at order create, deliver after 30m), reminders.

Example 4: When to use RocketMQ

Scenario	Feature	Note
Order per entity	Ordered message (sharding key)	Same key → same queue
Delayed task	Delay message	Fixed levels (e.g. 1s–2h)
Filter by type	Tag + filter	One topic, multiple tags
Broadcast	Broadcast consumer group	Every consumer gets every message
Transactional outbox	Transaction message API	Send and commit in one transaction

Core Mechanism / Behavior

• Broker: Stores messages by topic and queue (similar to Kafka partition). Replication and master/slave for HA. Consumers pull from broker; broker can push (long polling).
• Offset: Consumer commits offset to broker; on restart, consumption resumes from last commit. At-least-once by default (commit after process).
• Transaction message: Half message is sent; if local transaction succeeds, commit; else rollback. Broker delivers only committed messages. Use for “send message and update DB” in one logical transaction.

Key Rules

• Use tags to separate event types within a topic and filter on the consumer side; keeps one topic but allows selective consumption. Use ordered message when you need order per key; choose sharding key (e.g. orderId) consistently.
• Delay messages have fixed levels; choose the level that matches your delay (e.g. 30m for order timeout). For more flexible delay, use a delay topic + scheduled consumer or external scheduler.
• Design consumers to be idempotent; use transactional message when you need “DB + send” consistency and accept the complexity.

What's Next

See Kafka Core Concepts and Ordering vs Throughput for comparison. See Retry and DLQ Strategy for failure handling. See Idempotency in Message Consumers for safe consumption.