This topic describes terms that are used in ApsaraMQ for RocketMQ to help you better understand and use ApsaraMQ for RocketMQ.
Topic
A topic is a top-level container in ApsaraMQ for RocketMQ for message transmission and storage. It is used to identify messages that belong to the same business category. A topic is uniquely identified by its name. For more information, see Topics.
Lite topic
If a topic is of the Lite type, lite topics can be created under it. The storage container for messages is uniquely identified by the combination of the topic and the lite topic. By default, each storage container consists of one queue. For more information, see Lite topic model.
Message type
A message type is a classification of messages in ApsaraMQ for RocketMQ based on their transmission characteristics. Message types are used for type management and security verification. ApsaraMQ for RocketMQ supports normal messages, ordered messages, transactional messages, and scheduled and delayed messages.
Message queue
A message queue is the actual container for storing and transmitting messages in ApsaraMQ for RocketMQ. It is also the smallest storage unit for messages. All topics in ApsaraMQ for RocketMQ consist of multiple queues. This design enables horizontal splitting of queues and streaming storage within each queue. Queues are uniquely identified by their QueueId. For more information, see Message queues.
Message
A message is the smallest unit of data transmission in ApsaraMQ for RocketMQ. A producer encapsulates the payload and extended properties of business data into a message and sends it to the ApsaraMQ for RocketMQ server. The server then delivers the message to a consumer for processing based on the relevant semantics. For more information, see Messages.
The message ID in ApsaraMQ for RocketMQ is globally unique and does not repeat across different topics. However, in scenarios such as network fluctuations or consumption failure retries, a message may be delivered multiple times. Implement idempotent processing on the consumer side by using the message key, rather than relying on the message ID for deduplication.
ApsaraMQ for RocketMQ does not modify the content of messages sent by producers, including field case, format, or any other attributes. The data in the message body remains in its original state as sent.
Message view
A message view is a read-only interface provided by ApsaraMQ for RocketMQ from a developer's perspective. A message view lets you read multiple properties and the payload of a message, but you cannot modify the message itself.
Message tag
A message tag is a property for fine-grained message classification in ApsaraMQ for RocketMQ. It allows for sub-categorization of messages under a topic. Consumers can use fine-grained filtering by subscribing to specific tags. For more information, see Message filtering.
Message offset
Messages are stored in the queues of a topic in the order they arrive at the ApsaraMQ for RocketMQ server. Each message in a queue has a unique Long-type coordinate. This coordinate is the message offset. For more information, see Consumer progress management.
Consumer offset
A message is not immediately deleted from a queue after it is consumed. For each consumer group, ApsaraMQ for RocketMQ records the offset of the most recently consumed message. This recorded offset is the consumer offset. For more information, see Consumer progress management.
Message key
A message key is an index property for messages provided by ApsaraMQ for RocketMQ. By setting a message key, you can quickly find the corresponding message content.
Producer
A producer is a running entity in the ApsaraMQ for RocketMQ system that builds and sends messages to the server. Producers are typically integrated into business systems. They encapsulate business data into ApsaraMQ for RocketMQ messages and send them to the server. For more information, see Producers.
Transaction checker
A transaction checker is a listener used by producers in ApsaraMQ for RocketMQ to perform local transaction checks and recover from abnormal transactions. A transaction checker must check and determine the resolution of a transactional message based on the status of the business data. For more information, see Transactional messages.
Transaction resolution
Transaction resolution is an identifier for the commit status of a transactional message during the sending process in ApsaraMQ for RocketMQ. The server uses the transaction resolution to control whether the transactional message is committed and delivered. Transaction resolutions include commit, rollback, and pending. For more information, see Transactional messages.
Consumer group
A consumer group is a load balancing group in the ApsaraMQ for RocketMQ system that contains multiple consumers with identical consumption behaviors. Unlike a consumer, a consumer group is a logical resource, not a running entity. In ApsaraMQ for RocketMQ, initializing multiple consumers within a consumer group achieves horizontal scaling for consumption performance and high-availability disaster recovery. For more information, see Consumer groups.
Consumer
A consumer is a running entity in ApsaraMQ for RocketMQ that receives and processes messages. Consumers are typically integrated into business systems. They retrieve messages from the ApsaraMQ for RocketMQ server and convert them into business-intelligible information for processing by business logic. For more information, see Consumers.
The message push method depends on the consumption mode. In clustering consumption mode, messages are distributed by queue. Messages in the same queue are delivered serially, while messages in different queues can be pushed concurrently. In broadcasting consumption mode, each message is pushed to all consumers. For ordered messages, messages are delivered in order within the same queue, and the next message is not delivered until the previous one has been fully processed.
Consumption result
The consumption result is returned by a PushConsumer's listener in ApsaraMQ for RocketMQ after it finishes processing a message. It indicates whether the message was processed correctly. Consumption results include success and failure.
Subscription
A subscription is the rule and status configuration for how consumers retrieve and process messages in the ApsaraMQ for RocketMQ system. A subscription is dynamically registered by a consumer group with the server. During subsequent message transmissions, filtering rules defined in the subscription are used for message matching and consumer progress maintenance. For more information, see Subscriptions.
Message filtering
Consumers can filter messages by subscribing to specific message tags (Tags) to ensure they receive only the filtered set of messages. The calculation and matching of filtering rules are completed on the ApsaraMQ for RocketMQ server. For more information, see Message filtering.
Consumer offset resetting
This feature resets the consumption progress of a consumer group for its subscribed topics to a specific point in time. After the reset, consumers receive messages sent by producers to the ApsaraMQ for RocketMQ server after the specified point in time. For more information, see Reset consumer offsets.
Message trace
A message trace provides the complete link information of a message. This information is aggregated from data, such as time and location, from each relevant node as the message travels from a producer to a consumer. A message trace lets you clearly see the complete path of a message from the producer, through the ApsaraMQ for RocketMQ server, to the consumer. This helps with troubleshooting and problem diagnosis.
Message accumulation
Message accumulation occurs when producers send messages to the ApsaraMQ for RocketMQ server faster than consumers can process them. The unconsumed messages are stored on the ApsaraMQ for RocketMQ server.
Transactional message
A transactional message is an advanced message type provided by ApsaraMQ for RocketMQ. It ensures eventual consistency between message production and local transactions in a distributed scenario.
Scheduled and delayed message
A scheduled and delayed message is an advanced message type provided by ApsaraMQ for RocketMQ. After a message is sent to the server, it can be consumed by consumers only after a specified time. By setting a specific delay time, you can achieve delayed scheduling and triggering effects in distributed scenarios.
Ordered message
An ordered message is an advanced message type provided by ApsaraMQ for RocketMQ. It ensures that consumers receive messages in the same order that they were sent. This enables sequential processing in business scenarios.
Lite message
A lite message is an advanced message type provided by ApsaraMQ for RocketMQ. It supports the dynamic creation of millions of lite topics and provides features such as automated lifecycle management and high-performance subscriptions. For more information, see Lite topic model.
FAQ
Should I use the domain name or IP address of the internal endpoint when accessing ApsaraMQ for RocketMQ across VPCs?
Use the VPC endpoint domain name provided in the ApsaraMQ for RocketMQ console — the domain with the -vpc suffix, for example, rmq-cn-ai54re6l701-vpc.cn-guangzhou.rmq.aliyuncs.com:8080. This domain is designed for internal network access. Combined with VPC peering connections and the correct routing and DNS configuration, it enables connectivity between VPCs. Using an IP address directly may cause connection failures.
What should I pay attention to when migrating from AWS SQS to ApsaraMQ for RocketMQ?
When migrating from AWS SQS to ApsaraMQ for RocketMQ, note the following:
Adapt your client to use the gRPC SDK and set the Namespace to the instance ID.
Use the private network endpoint to avoid Internet traffic fees.
Control the message size to 4 KB or less to reduce the number of send and receive operations and maximize the free quota of 20 million operations per month.
What should I do if I get an AccessDenied error when downloading the RocketMQ ONS .NET SDK for Linux?
The public download link may be inaccessible due to OSS permission configuration issues. If you encounter an AccessDenied error, check whether you are using an expired public link. Obtain the latest SDK download link from the official documentation or search for the corresponding version in Alibaba Cloud SDK Center.
What is the difference in concurrent processing capability between the Remoting protocol and the gRPC protocol within the same consumer group?
In the same consumer group:
gRPC protocol (5.x): Supports distributing messages to different threads by MessageGroup for concurrent consumption, which improves throughput. This feature requires gRPC SDK version 5.0.3 or later.
Remoting protocol (4.x): Supports only single-threaded sequential consumption and does not support parallel processing by MessageGroup.
Are topic and consumer group resources isolated when two instances run in parallel? Will messages be misrouted?
Resources are isolated between instances because each instance has a unique instance ID. Messages will not be misrouted. As long as PropertyKeyConst.NAMESRV_ADDR in the client configuration points to the correct endpoint of the corresponding instance, topics and consumer groups with the same names in different instances will not interfere with each other.
Can TCP and HTTP endpoints be used interchangeably?
No. TCP and HTTP endpoints are not interchangeable:
TCP SDKs must be configured with a TCP endpoint.
HTTP SDKs must be configured with an HTTP endpoint.
For ons-client-2.0.6.Final (typically used for the TCP protocol), use the region-specific TCP endpoint address.