- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- RocketMQ 5.x
- RocketMQ 4.x
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- SDK Documentation
- Migration to Cloud
- API Documentation
- FAQs
- TDMQ FOR ROCKETMQ SERVICE LEVEL AGREEMENT
- Contact Us
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- RocketMQ 5.x
- RocketMQ 4.x
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- SDK Documentation
- Migration to Cloud
- API Documentation
- FAQs
- TDMQ FOR ROCKETMQ SERVICE LEVEL AGREEMENT
- Contact Us
Naming Conventions for Common Concepts of RocketMQ
Last updated: 2024-03-18 14:53:27
This document introduces the naming conventions and usage norms for common concepts in RocketMQ.
Naming Conventions
topic
It must not be empty, and can only contain letters, digits, (-), and (_), 3 to 64 characters.
Suggested format: String.format (tp_%s_%s, system name, and business name)
For example: tp_order_check
tag
Can be empty, as long as it is a string, used for secondary message filtering under a topic.
Suggested format: String.format (tag_%s, business action or category)
For example: tag+business action, e.g., the tag for order creation is tag_create; the tag for order closure is tag_close
keys
Can be empty, recommended setting, as long as it is a string or an array of strings, used for querying messages or message traces in the console.
Suggested format: String.format (%s and unique business ID)
For example: order ID, transaction ID or serial number, TraceID, and other unique IDs
producer group
It must not be empty, 3 to 64 characters, and can only contain letters, digits, (-), and (_).
Suggested format: String.format (pg_%s_%s, system name, and business name)
For example: pg_transfer_check
consumer group
It must not be empty, 3 to 64 characters, and can only contain letters, digits, (-), and (_).
Suggested format: String.format (cg_%s_%s, system name, and business name)
For example: cg_transfer_check
role
It must not be empty, supports only digits, upper and lower case letters, and delimiters (_, -), and cannot exceed 32 characters.
Markers for different business read and write permissions, suggested format: business name + send/consume
For example: role_order_send, role_order_consume, and role_order_all
clientId
clientId represents a client instance ID, which must be unique across different clients. clientId cannot be directly set on the client. instanceName is an optional component of clientId, which can modify the clientId by adjusting instanceName.
Classification | Generating Strategy |
Producer | ${currentIP}@${instanceName} |
Cluster Consumer | ${currentIP}@${instanceName} |
Broadcast Consumer | ${currentIP}@${instanceName} |
public String buildMQClientId() { StringBuilder sb = new StringBuilder(); sb.append(this.getClientIP()); sb.append("@"); sb.append(this.getInstanceName()); if (!UtilAll.isBlank(this.unitName)) { sb.append("@"); sb.append(this.unitName); } if (enableStreamRequestType) { sb.append("@"); sb.append(RequestType.STREAM); } return sb.toString(); }
instanceName
Instance names, under default scenarios, do not require special settings by the user. The system will generate a unique value randomly through the following code by default.
public void changeInstanceNameToPID() { if (this.instanceName.equals("DEFAULT")) { this.instanceName = UtilAll.getPid() + "#" + System.nanoTime(); } }
Broadcast consumers, upon every startup, need to keep the instance name constant to read the local progress file on the client. It is required to set the instanceName explicitly, and broadcast consumption must ensure the current Client IP remains unchanged before and after startup. If deploying in a container, it is necessary to set a fixed pod IP for scheduling; otherwise, broadcast messages during the restart period will be missed.
Suggested format: String.format (instance-%s-%s, system name, and business name).
Usage Guidelines
Producer
[Mandatory] A domain service can only have one topic.
[Mandatory] When sending messages, a domain service must set the tag according to the business action.
[Mandatory] The keys must be set when the producer sends a message.
[Mandatory] Logs must be printed whether a message sending succeeded or failed, with both the SendResult and key fields required to be printed.
[Recommended] After a message-sending failure, it is recommended to store the message in a database, and then use a timer-like thread for periodic retries to ensure the message can be delivered to the broker.
[Recommended] For business scenarios where reliability is not a high requirement, the oneway messages can be used.
[Mandatory] When creating a new producer, a producer group must be specified.
Consumer
[Mandatory] When creating a new consumer, a producer group must be specified.
[Mandatory] Message consumers cannot avoid duplicate messages, so the business service needs to ensure idempotent message consumption.
[Recommended] To improve consumption parallelism, you can start multiple Consumer instances under the same ConsumerGroup or increase the parallel consumption capacity of a single Consumer by modifying ConsumeThreadMin and ConsumeThreadMax.
[Recommended] To increase business throughput, you can batch the consume messages by setting the consumer's consumeMessageBatchMaxSize.
[Recommended] In the event of message accumulation, if the business does not have high data requirements, you can choose to discard unimportant messages.
[Recommended] If the message volume is small, it is recommended to print messages and consumption time, etc. at the entry point of consumption to facilitate subsequent troubleshooting.
Yes
No
Was this page helpful?