This topic describes the definition, model relationship, internal attributes, behavior constraints, version compatibility, and usage notes of topics in ApsaraMQ for RocketMQ.
Definition
In ApsaraMQ for RocketMQ, a topic is a top-level container that is used to transmit and store messages. Messages in a topic use the same consumption logic.
Topics provide the following benefits:
Message categorization and isolation
When you use ApsaraMQ for RocketMQ, we recommend that you use different topics to manage messages of different business types for isolated storage and subscriptions.
Identity and permission management
Messages in ApsaraMQ for RocketMQ are anonymous. You can use a topic to perform identity and permission management 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 storage container in which all message resources are defined. A topic is not the actual unit that stores messages but a logical concept.
A topic contains one or more queues to facilitate message storage and scaling. All constraints and attribute settings of a topic are implemented based on the queues in the topic.
Internal attributes
Behavior constraints
Forcible message type verification
In ApsaraMQ for RocketMQ 5.x, message types are maintained and processed separately in topics. The system forcibly verifies the type of sent messages against the message type defined for a topic. If the verification fails, message delivery requests are rejected, and a type mismatch error is returned. The following verification rules apply:
Message types must be consistent
The type of messages that are sent must be the same as the message type that is specified for the destination topic.
Only one type of message is sent to a topic
Only one type of message can be sent to a topic.
Examples of incorrect usage
Send messages that do not match the message type of a topic
For example, the normal message type is specified for a topic, but transactional messages are sent to the topic. In this case, message sending requests are rejected and a message type mismatch error is returned.
Send messages of different types to a topic
For example, the normal message type is specified for a topic, but normal messages and ordered messages are sent to the topic. In this case, requests corresponding to ordered messages are rejected and a message type mismatch error is returned.
Version compatibility
Forcible message type verification takes effect only on ApsaraMQ for RocketMQ 5.x brokers.
If you use an ApsaraMQ for RocketMQ 4.x broker, we recommend that the type of sent messages be consistent with the message type defined for a topic even though forcible message type verification is not performed.
Usage notes
Plan topics based on your business requirements
When you plan topics in ApsaraMQ for RocketMQ, use one topic to process messages that have the same attributes. When you plan topics, take note of the following points:
Message types: Use different topics to manage different types of messages. For example, you can create two topics to separately manage ordered messages and normal messages.
Message correlation: Use separate topics to manage messages that are not directly correlated. For example, create two topics for Taobao transaction messages and Freshippo logistics messages. If messages are directly correlated, you can use the same topic. For example, you can create one topic for order messages that are produced for men's clothing and women's clothing on Taobao. If business volume or submodules require fine-grained topics, you can use different topics for messages that can be further classified. For example, you can create two topics for messages that are produced for men's clothing and women's clothing on Taobao.
Message volume and timeliness: Use different topics to process messages that differ in volume or timeliness. For example, do not use the same topic for a service that generates a small number of time-sensitive messages and a service that generates trillions of messages. This prevents prolonged waiting periods for time-sensitive messages.
Example of correct topic planning: In e-commerce scenarios, you can use a topic for order-related messages, such as order creation, payment, and cancellation messages, a topic for logistics messages, and a topic for reward point-related messages.
Examples of incorrect topic planning:
Excessively coarse granularity: This causes poor isolation and hinders independent O&M and fault handling. For example, you use the same topic for all transaction messages and logistics messages.
Excessively fine granularity: This consumes a large number of topic resources and increases the system load. For example, you use a separate topic for messages that are produced for each user.
Use a topic to send and receive messages of the same type
Topic-based business isolation is a design principle of ApsaraMQ for RocketMQ. We recommend that you use different topics for messages that use different business logic. Each topic can be used to send or receive messages of a specific type.
Prevent automated management of topics
Topics in ApsaraMQ for RocketMQ are top-level resources and containers that provide separate permission management, observability metrics collection, and monitoring capabilities. System resources are required to create and manage topics. We recommend that you add, delete, modify, and query topics in production environments only when the operations are required.