This topic describes the definition, model relationship, internal attributes, behavioral constraints, version compatibility, and usage notes for topics in ApsaraMQ for RocketMQ.
Definition
In ApsaraMQ for RocketMQ, a topic is a top-level container for transmitting and storing messages. A topic identifies messages that share the same business logic.
Topics provide the following benefits:
Data categorization and isolation
When you design solutions that use ApsaraMQ for RocketMQ, you can create different topics to manage messages of different business types. This practice ensures isolated storage and subscriptions.
Identity and permission management
Messages in ApsaraMQ for RocketMQ are anonymous. You can use a topic to manage identities and permissions for messages of a specific category.
Model relationship
The following figure shows the position of a topic in the domain model of ApsaraMQ for RocketMQ.
In ApsaraMQ for RocketMQ, a topic is a top-level container for all message resources. However, a topic is a logical concept and not the actual message container.
A topic consists of one or more queues that handle message storage and horizontal scaling. All constraints and attribute settings for a topic are implemented at the queue level.
If a topic is of the Lite type, you can create LiteTopic resources under it. By default, each LiteTopic consists of one queue.
Concepts
Topic
In ApsaraMQ for RocketMQ, a topic is a top-level container for transmitting and storing messages. It identifies messages that share the same business logic and is uniquely identified by its topic name.
LiteTopic
If a topic is of the Lite type, you can create LiteTopics under it. The combination of the topic and the LiteTopic uniquely identifies the message storage container. By default, each storage container consists of one queue.
Internal attributes
Behavior constraints
Forcible message type verification
In ApsaraMQ for RocketMQ 5.x, message types are managed and processed independently within topics. The system verifies the type of a sent message against the message type defined for the destination topic. If the verification fails, the send request is rejected, and the system returns a type mismatch exception. The following verification rules apply:
Message type consistency
The type of the sent message must match the message type defined for the destination topic.
Single message type per topic
Each topic supports only one message type. You cannot send messages of different types to the same topic.
Common incorrect usage scenarios
Sending messages of a mismatched type
For example, if you create a topic and define its message type as ordered, but then send a transactional message to this topic, the send request is rejected and a type mismatch exception is returned.
Mixing message types in a single topic
For example, you create a topic and define its message type as normal. If you then send both normal messages and ordered messages to this topic, the requests to send the ordered messages are rejected, and a type mismatch exception is returned.
Version compatibility
Enforced message type verification applies only to ApsaraMQ for RocketMQ 5.x brokers.
ApsaraMQ for RocketMQ 4.x brokers do not enforce message type verification. However, we recommend that you maintain message type consistency when you use these brokers.
Usage notes
Plan topics based on business categories
When you design topics in ApsaraMQ for RocketMQ, we recommend that you group messages by major business category. Group messages that have the same functional attributes within the same business domain into a single topic. When you determine the topic granularity, consider the following factors:
Message type consistency: Different message types, such as ordered messages and normal messages, require different topics.
Business relevance: If businesses are not directly related, use different topics. For example, Taobao transaction messages and Freshippo logistics messages have no business overlap and require different topics. For messages within the same business, such as Taobao transaction messages, you can use the same topic for orders of both women's and men's clothing. However, if the business volume is large or if submodules require further categorization of order types, you can also split the messages into two separate topics for men's and women's clothing orders.
Message volume: We recommend that you use different topics for business messages that differ in magnitude or timeliness requirements. For example, some business messages have a very small volume but are highly time-sensitive. If these messages share a topic with a business that generates a high volume of messages, the wait time for the time-sensitive messages increases.
Example of correct topic splitting: In an online shopping scenario, you can use one topic for order transaction messages, such as order creation, payment, and cancellation. You can use a separate topic for logistics-related messages and another topic for points management messages.
Examples of incorrect topic splitting:
Splitting with excessively coarse granularity: This leads to poor business isolation and complicates independent O&M and fault handling. An example is using a single topic for all transaction and logistics messages.
Splitting with excessively fine granularity: This consumes excessive topic resources and can overload the system. An example is creating a separate topic for each user ID.
Use a single topic for one message type and avoid mixing types
Topics in ApsaraMQ for RocketMQ are designed to isolate businesses. We recommend that you use different topics for messages with different business logic. Messages with the same business logic have the same message type. Therefore, a single topic should be used for only one type of message.
Avoid using automated mechanisms for topic management
In the ApsaraMQ for RocketMQ architecture, topics are top-level resources and containers. They have independent capabilities for permission management, observability metrics collection, and monitoring. Creating and managing topics consumes system resources. Therefore, you must strictly manage topic resources in a production environment. Do not arbitrarily add, delete, modify, or query topics.