All Products
Search
Document Center

ApsaraMQ for RocketMQ:Topics

Last Updated:Aug 20, 2024

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

Topic names

  • Definition: the name of a topic. A topic name identifies the topic and is globally unique in a cluster.

  • Value: A topic name is specified by the user when a topic is created.

  • Constraints: For more information, see Limits on parameters.

Queues

  • Definition: the actual storage units that store messages. A topic contains one or more queues. For more information, see Message queues.

  • Value: You can specify the number of queues when you create a topic. ApsaraMQ for RocketMQ allocates the specified number of queues to the topic.

  • Constraints: A topic must contain at least one queue.

Message types

  • Definition: the type of messages in a topic.

  • Value: You can select one of the following message types when you create a topic in ApsaraMQ for RocketMQ:

    • Normal: normal messages. A normal message does not require special semantics and is not correlated with other normal messages.

    • FIFO: ordered messages. ApsaraMQ for RocketMQ uses a message group to determine the order of a specific set of messages. The messages are delivered in the order in which the messages are sent.

    • Delay: scheduled and delayed messages. If you do not want to immediately deliver messages, you can specify a delay for the messages. This way, the messages become available to consumers when the delay elapses.

    • Transaction: transactional messages. ApsaraMQ for RocketMQ supports distributed transactional messages and ensures transaction consistency of database updates and message calls.

  • Constraints: A topic can be used to send and receive only one type of message.

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.