This topic describes the definition, model relationship, internal attributes, and behavior constraints of messages in ApsaraMQ for RocketMQ. This topic also provides usage notes for messages.
Definition
A message is the smallest unit of data transmission in ApsaraMQ for RocketMQ. A producer encapsulates the load and extended attributes of business data into messages and sends the messages to a ApsaraMQ for RocketMQ broker. Then, the broker delivers the messages to the consumer based on the relevant semantics.
- Immutability
A message is an event that is generated. After the message is generated, the content of the message does not change. Even if the message passes through a transmission channel, the content of the message remains the same. The messages that consumers obtain are read-only messages.
- Persistence
By default, ApsaraMQ for RocketMQ persists messages. The received messages are stored in the storage file of the ApsaraMQ for RocketMQ broker to ensure that the messages can be traced and restored if system failures occur.
Model relationship
- Messages are initialized by producers and are sent to the ApsaraMQ for RocketMQ broker.
- Messages are stored in queues in the order in which the messages are received on the ApsaraMQ for RocketMQ broker.
- Consumers obtain and consume messages from the ApsaraMQ for RocketMQ broker based on the specified subscriptions.
Internal attributes
System attributes
- Definition: the name of the topic to which a message belongs. The topic name is globally unique in a cluster. For more information, see Topics.
- Values: obtained from the client SDK.
- Definition: the type of a message.
- Values: obtained from the client SDK. ApsaraMQ for RocketMQ supports the following message types:
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.
- Definition: the queue to which a message belongs. For more information, see Message queues.
- Values: specified and populated by the broker.
- Definition: the location where the current message is stored in the queue. For more information, see Working mechanism.
- Values: specified and populated by the broker. Valid values: 0 to Long.Max.
- Definition: the unique identifier of a message. The ID of each message is globally unique in the cluster.
- Values: automatically generated by the producer client. A message ID is a string of 32 characters that consists of digits and uppercase letters.
- Definition: the list of index keys for messages. You can configure different keys to distinguish between messages and quickly find messages.
- Values: defined by the producer client.
- Definition: the tag that is used to filter messages. Consumers can filter messages by tags and receive only messages that contain specified tags.
- Values: defined by the producer client.
- Constraint: Only one tag can be specified for each message.
- Definition: the millisecond-level timestamp that is used when a message triggers delayed delivery in a scheduled time scenario. For more information, see Scheduled and delayed messages.
- Values: defined by the message producer.
- Constraints:
Subscription and pay-as-you-go Standard Edition instances and serverless Standard Edition and Professional Edition instances: 7 days.
Subscription and pay-as-you-go Professional Edition and Enterprise Platinum Edition instances: 40 days.
For more information, see Quotas and limits.
- Definition: the local millisecond-level timestamp of the producer client when the message is sent.
- Values: populated by the producer client.
- Note: The client time may be different from the broker time. In this case, the message sending time is based on the client time.
- Definition: the local millisecond-level timestamp of the ApsaraMQ for RocketMQ broker when the message is stored.
For scheduled messages and transactional messages, the message retention time is the broker time that is displayed for the consumer when the message takes effect.
- Values: populated by the broker.
- Note: The client time may be different from the broker time. In this case, the message retention time is based on the broker time.
- Definition: the number of times that the ApsaraMQ for RocketMQ broker redelivers a message after the message fails to be consumed. After each retry, the number of retries is increased by 1. For more information, see Consumption retry.
- Values: labeled by the broker. The first time that a message is consumed, the number of retries is 0. The first time that a message fails to be consumed, the number of retries is 1.
Custom attributes for messages
- Definition: the extended information that can be specified by the producer.
- Values: specified by the producer based on key-value pairs from a string.
Message load
- Definition: the actual message data of the service message.
- Values: serialized by the producer and transmitted in binary bytes.
- Constraints: For more information, see Limits on parameters.
Behavior constraints
The size of a message cannot exceed the upper limit. If the size of a message exceeds the corresponding upper limit, the message fails to be sent.
- A normal message or an ordered message: 4 MB
- A transactional message, scheduled message, or delayed message: 64 KB
Usage notes
Overloaded transmission is not recommended for a single message.
ApsaraMQ for RocketMQ is a messaging middleware that transmits data for service events. If the size of a message is large, the network transmission layer may be overloaded. This affects retries upon errors and throttling. We recommend that you limit the data size of a single message event.
If an overloaded transmission is required in the production environment, we recommend that you split the message based on a fixed size or use the file storage method.
Immutability of messages
Messages cannot be modified in ApsaraMQ for RocketMQ broker versions 5.x, and the messages that consumers obtain are read-only messages.
Because 3.x and 4.x versions do not have immutability constraints, you must re-initialize the messages if you want to forward them.
- Correct example:
Message m = Consumer.receive(); Message m2= MessageBuilder.buildFrom(m); Producer.send(m2);
- Incorrect example:
Message m = Consumer.receive(); m.update(); Producer.send(m);