ApsaraMQ for RocketMQ:Quotas and limits

Parameter

Limit

Description

Instance name

• An instance name can contain only letters, digits, and underscores (_).

• An instance name must be 1 to 128 characters in length.

None.

Topic name

• A topic name can contain letters, digits, underscores (_), and hyphens (-).

• A topic name must be 1 to 60 characters in length.

A topic name cannot contain the following strings that are reserved for the system or strings that contain special prefixes:

• Strings reserved for the system

  • TBW102

  • BenchmarkTest

  • SELF_TEST_TOPIC

  • OFFSET_MOVED_EVENT

  • SCHEDULE_TOPIC_XXXX

  • RMQ_SYS_TRANS_HALF_TOPIC

  • RMQ_SYS_TRACE_TOPIC

  • RMQ_SYS_TRANS_OP_HALF_TOPIC

• Special prefixes

  • rmq_sys_

  • %RETRY%

  • %DLQ%

  • rocketmq-broker-

When you specify names for topics, you must use short strings of common characters. Do not use special characters. If you use special characters in a topic name, exceptions may occur during system parsing. If a topic name is excessively long, the system may refuse to send and receive messages.

Consumer group name

• A consumer group name can contain letters, digits, underscores (_), and hyphens (-).

• A consumer group name must be 1 to 60 characters in length.

A consumer group name cannot contain the following strings that are reserved for the system or strings that contain special prefixes:

• Strings reserved for the system

  • DEFAULT_CONSUMER

  • DEFAULT_PRODUCER

  • TOOLS_CONSUMER

  • FILTERSRV_CONSUMER

  • __MONITOR_CONSUMER

  • CLIENT_INNER_PRODUCER

  • SELF_TEST_P_GROUP

  • SELF_TEST_C_GROUP

  • CID_ONS-HTTP-PROXY

  • CID_ONSAPI_PERMISSION

  • CID_ONSAPI_OWNER

  • CID_ONSAPI_PULL

  • CID_RMQ_SYS_TRANS

• Special prefixes

  • CID_RMQ_SYS_

  • CID_HOUSEKEEPING

None.

Instance description

• The description of an instance, a topic, or a group can contain only letters, digits, and underscores (_).

• The description of an instance, a topic, or a group must be 1 to 256 characters in length.

None.

Topic description

Group description

ACL credential

• An AccessKey ID, an AccessKey secret, or a token can contain only letters and digits.

• An AccessKey ID, an AccessKey secret, or a token must be 1 to 1,024 characters in length.

None.

Request timeout period

• Default value: 3000. Unit: milliseconds.

• The value of this parameter varies based on the client. No limit is imposed on the value of the parameter.

The request timeout period is the period of time for which the client waits before the client synchronously calls API operations. Specify a suitable value for this parameter to prevent threads from being blocked for a long period of time.

Message size

A message cannot exceed 4 MB in size.

Only the size of the message body is calculated.

When you transmit a message, you must compress the size of the load to prevent overloaded file transmissions. If the size of a message exceeds the upper limit, you can split the message or store the message in Object Storage Service (OSS). If you store the message in OSS, the producer can use the URL based on which the message is stored to send the message.

Custom message attribute

• The name of a custom message attribute can contain all visible characters.

• You can configure up to 128 attributes for each message.

• The total length of the keys and values of all attributes cannot exceed 16 KB.

You cannot use attribute names that are reserved for the system as attribute keys.

None.

Message group

• A message group name can contain all visible characters.

• A message group name must be 1 to 64 bytes in length.

A message group is used to identify a group of ordered messages. You can set this parameter to a shared property based on which the messages are sent or received in order, such as order IDs and user IDs.

Message sending retries

• Default value: 3.

• No limit is imposed on the number of retries for sending a message.

The message sending retry feature is a built-in feature in client SDKs and cannot be viewed on applications. To prevent threads from being blocked, we recommend that you do not specify a large value for this parameter.

If a message is not sent after the maximum number of retries is reached, we recommend that you take measures on the business side to ensure the availability of the message.

Message consumption retries

• Default value: 16.

• Maximum value: 1000.

You must configure this parameter based on your business requirements to prevent messages from being retried an excessive number of times. A large number of consumption retries may cause the system to be overloaded.

Interval for transaction exception checks

• Default value: 60. Unit: seconds.

• You cannot change the value of this parameter.

If a half message fails to be committed due to a system restart or an exception, the producer checks the status of the transaction based on the interval that is specified by this parameter.

Frequent checks that are performed on transaction status may reduce system performance. To ensure system performance, we recommend that you do not specify a small value for this parameter.

Time period for the first check of half messages

• The default value is equal to the value of the interval for transaction exception checks parameter.

• Maximum value: 1. Unit: hours.

None.

Maximum timeout period for half messages

• Default value: 4. Unit: hours.

• You cannot change the value of this parameter.

If a half message fails to be committed due to a system restart or an exception, the producer checks the status of the transaction based on the interval that is specified by the interval for transaction exception checks parameter. If the result is not returned after the maximum timeout period that is specified for the half message is elapsed, the half message is forcefully rolled back.

You can monitor this parameter to prevent abnormal transactions.

Maximum interval for sending scheduled messages

• Default value: 24. Unit: hours.

• You cannot change the value of this parameter.

We recommend that you specify the interval for sending scheduled messages by hour to prevent the interval from being too long.

Consumption timeout period for push consumers

• Default value: 1. Unit: minutes.

• This is a system parameter. You cannot change the value of this parameter.

The timeout period for push consumers is centrally managed by the ApsaraMQ for RocketMQ broker.

If a message is not consumed after the consumption timeout period is elapsed, the system determines that the message consumption failed and retries the message. In this case, a small number of messages may be duplicated.

Local caching for push consumers

• Default values:

  • Maximum number of cached messages: 1024.

  • Maximum size of a cached message: 64 MB.

• You cannot change the value of this parameter. No limit is imposed on the value of the parameter.

If the consumers are push consumers, specific messages are cached in the local storage of the SDK client to improve consumer throughput and performance. When you specify the maximum number of cached messages and maximum size of a cached message, you must make sure that the values are in the ranges that are allowed by the system.

Retry interval for push consumers

• Default values:

  • Non-ordered delivery: incremental. For more information, see Retry policies for messages consumed in Push mode.

  • Ordered delivery: 1000. Unit: milliseconds.

• You cannot change the value of this parameter.

None.

Concurrent threads for push consumers

• Default value: 20.

• You cannot change the value of this parameter. No limit is imposed on the value of the parameter.

None.

Maximum number of messages that can be pulled at a time

• Default value: 32.

• This is a system parameter. You cannot change the value of this parameter.

This parameter specifies the maximum number of messages that can be pulled from the client at a time when a consumer consumes messages. We recommend that you specify the value of the parameter based on your business requirements. If the value of the parameter is too large, a large number of messages may be duplicated if consumption fails.

Maximum invisible period for simple consumers

• This parameter is required, and no default value is specified.

• Valid range: 10 seconds to 12 hours.

Consumption invisible period is calculated by using the following formula: Consumption invisible period = Time period for processing a message + Retry interval. We recommend that you specify a larger value for this parameter than the actual period of time that is required.

Consumer long polling timeout

Valid range: 5 to 20. Unit: seconds.

You can specify a custom value within the valid range.

If no ready message is available on the ApsaraMQ for RocketMQ broker after you configure this parameter, requests from clients are blocked until the broker receives new messages or the timeout period is reached.

The long polling feature of ApsaraMQ for RocketMQ can reduce the number of empty requests and the workloads on the client and the broker when the message volume is low.

Item

Limit

Description

Instances in a single region

You can create up to 1,000 instances in a single region.

None.

Messaging TPS of a single instance

The messaging transactions per second (TPS) of a single instance varies based on the specification that you purchase. For more information, see Limits on instance specifications.

Messaging TPS indicates the performance of an instance. If your actual TPS usage exceeds the specification limit, your instance is throttled. In this case, we recommend that you upgrade your specification at your earliest opportunity.

Topics on a single instance

The number of topics that you can create on a single instance varies based on the specification that you purchase. For more information, see Limits on instance specifications.

To ensure business security and stability, we recommend that you use different instances to process different workloads.

Groups on a single instance

The number of groups that you can create on a single instance varies based on the specification that you purchase. For more information, see Limits on instance specifications.

To ensure business security and stability, we recommend that you use different instances to process different workloads.

Message retention period

• Minimum value: 24. Unit: hours.

• Maximum value: 720. Unit: hours.

If your storage funds are sufficient, we recommend that you specify a longer retention period. A longer retention period allows the system to troubleshoot issues and backtrack messages within a longer time window.

Inflight messages in a single consumer group

Maximum value: 2500.

Slow responses from the consumers in a consumer group may cause a large number of inflight messages. To ensure normal business running, handle the issue at your earliest opportunity.

Item

Description

Compatibility with Apache RocketMQ admin tools

ApsaraMQ for RocketMQ does not support the management of instances, topics, and groups by calling Apache RocketMQ Admin API or using the Apache RocketMQ CLI admin tool.

If you want to call API operations to manage your ApsaraMQ for RocketMQ resources, we recommend that you use OpenAPI Explorer provided by Alibaba Cloud. OpenAPI Explorer supports the management of resources by using SDKs for multiple programming languages and CLI commands.

Apache RocketMQ Request-Reply messages

ApsaraMQ for RocketMQ does not support the sending of Apache RocketMQ Request-Reply messages.

Apache RocketMQ Streaming

ApsaraMQ for RocketMQ does not support hosted Apache RocketMQ Streaming. You can deploy a streaming component based on your Alibaba Cloud environment. You can also configure lightweight data integration and computation by using the message integration feature provided by ApsaraMQ for RocketMQ.

Apache RocketMQ MQTT

ApsaraMQ for RocketMQ does not support hosted Apache RocketMQ MQTT. We recommend that you use ApsaraMQ for MQTT provided by Alibaba Cloud. Compared with Apache RocketMQ MQTT, ApsaraMQ for MQTT provides more features.

Apache RocketMQ EventBridge

ApsaraMQ for RocketMQ does not support hosted Apache RocketMQ EventBridge. We recommend that you use EventBridge provided by Alibaba Cloud. Compared with Apache RocketMQ EventBridge, Alibaba Cloud EventBridge provides more features.

Apache RocketMQ connectors

ApsaraMQ for RocketMQ does not support hosted Apache RocketMQ connectors. You can use the message integration feature provided by ApsaraMQ for RocketMQ to implement the message inflow and message outflow features.