TL;DR
- Scenario: When writing/reading RocketMQ documentation and code, concept confusion leads to high design and troubleshooting costs
- Conclusion: Use five main lines “component—consumption model—ordering—grouping—routing storage” to unify terminology
- Output: One-page quick reference: Producer/Consumer/Broker, Push/Pull, Group, ordered messages, Tag/Queue
RocketMQ Related Terminology
Message Model
RocketMQ is a distributed message middleware mainly composed of Producer, Broker, Consumer three parts.
1. Producer
- Responsible for creating and sending messages to Broker
- Supports three modes: synchronous sending, asynchronous sending, and one-way sending
- Can send multiple types of messages: normal messages, ordered messages, transaction messages, etc.
2. Broker
- Core component of RocketMQ, responsible for message storage and forwarding
- In actual deployment, each Broker corresponds to one physical server
- Uses master-slave architecture, supports data synchronization and failover
- Single Broker can store messages for multiple Topics
3. Consumer
- Responsible for subscribing to and consuming messages from Broker
- Supports cluster consumption and broadcast consumption modes
- Has message retry and dead letter queue mechanism to ensure message reliability
Message Queue
In RocketMQ, all message queues are persistent.所谓 length unlimited means each storage unit in the queue is fixed-length, accessing storage units uses Offset to access.
Consumer Group
A collection of the same type of Consumer is called Consumer Group. These Consumers usually consume messages from the same type of Topic and have the same consumption logic.
- Load Balancing: Multiple consumer instances within the same consumer group evenly distribute Topic’s message queues
- Fault Tolerance: When a consumer instance goes offline, the message queues it was responsible for automatically assign to other surviving consumer instances in the group
- Parallel Consumption: By increasing the number of instances within the consumer group, message consumption throughput can be improved
Cluster Consumption
Consumer instances in a Consumer Group evenly split message consumption. For example, if a Topic has 9 messages and one Consumer Group has 3 instances, each instance only consumes 3 of them.
Broadcast Consumption
In message queue systems, broadcast consumption mode means the same message will be sent to all consumers subscribed to that message. In this case, each consumer instance will independently consume the message.
ProducerGroup
The same type of Producer collection usually belongs to the same Producer Group. These Producers have the same configuration and business logic.
Transaction Message Sending Phase
- Producer first sends “half message” (Half Message) to Broker. At this time, message is invisible to consumers
- Broker persists and stores half message, returns acknowledgment
- Producer executes local transaction logic
Transaction State Confirmation Phase
- If original producer successfully executes local transaction, sends commit instruction to Broker
- If local transaction fails, sends rollback instruction
Ordered Messages
The order of message consumption must be the same as the order of message sending. In RocketMQ, this mainly refers to local ordering. To satisfy ordering for a type of messages, Producer must send single-threaded sequentially and to the same queue.
Normal Ordered Messages
- Sending end calculates hash modulo based on message’s specific attribute (e.g., order ID)
- Calculation result determines which specific message queue the message is sent to
- Messages of the same business ID are routed to the same queue, thus guaranteeing ordering
Strict Ordered Messages
A type of ordered message. It can guarantee ordering in both normal and abnormal situations, but sacrifices distributed Failover characteristic. As long as one machine in Broker cluster is unavailable, the entire cluster is unavailable.
Tag
A flag set for messages, used for different types of messages in the same partition. Messages from the same business unit can set different tags based on different business purposes under the same Topic.
Tags can effectively maintain code clarity and coherence, and optimize the query system provided by RocketMQ. Consumers can implement different consumption logic for different sub-topics based on Tag.
Error Quick Reference
| Symptom | Root Cause | Fix |
|---|---|---|
| Thinking “broadcast consumption = same group multi-instance sharing” | MessageModel=BROADCASTING, broadcast semantics are “each instance consumes once” | Use CLUSTERING; broadcast scenarios must ensure business idempotency |
| Instances in same Consumer Group have inconsistent subscriptions | Group instances not subscribed to exactly same Topic/Tag | Unify subscription configuration |
| Ordered messages occasionally out of order | Queue count change/expansion-contraction/failure switch causing routing to different queues | Normal ordering allows brief disorder; sensitive links avoid changing queue count |
| Transaction message half message backlog, repeated callbacks | Instances within ProducerGroup didn’t implement TransactionCheckListener | Deploy consistent business logic in same group |
| Tag filtering invalid/incorrect filtering | Producer sends Tag inconsistent with Consumer subscription expression | Unify Tag naming and subscription expression |
| Offset behavior inconsistent with expectation | Offset storage/reset strategy misunderstanding | Clarify “offset ownership = ConsumerGroup” |