Limits are imposed on resource quotas, instance specifications, and specific parameters of ApsaraMQ for RocketMQ. To prevent application exceptions, make sure that the limits are not exceeded when you use ApsaraMQ for RocketMQ.
Limits on parameters
The following table describes the parameters whose limits cannot be changed. To prevent system exceptions that are caused by special characters or limit exceeding, you must configure the parameters based on the conventions.
Parameter | Limit | Description |
Instance name |
| None. |
Topic name |
A topic name cannot contain the following strings that are reserved for the system or strings that contain special prefixes: | 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 cannot contain the following strings that are reserved for the system or strings that contain special prefixes: | None. |
Instance description |
| None. |
Topic description | ||
Group description | ||
ACL credential |
| None. |
Request timeout period |
| 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 transmission. 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 |
You cannot use attribute names that are reserved for the system as attribute keys. | None. |
Message group |
| 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 |
| 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 |
| 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 |
| 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 response parameters. |
Maximum timeout period for half messages |
| 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 |
| 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 |
| 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 |
| 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 |
| None. |
Concurrent threads for push consumers |
| None. |
Maximum number of messages that can be pulled at a time |
| 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 excessively large, a large number of messages may be duplicated if consumption fails. |
Maximum invisible period for simple consumers |
| 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. |
Limits on resource quotas
Based on O&M practices, ApsaraMQ for RocketMQ limits the quotas of metrics, such as queries per second (QPS) and concurrency, for specific operations to ensure stability in production environments. In most cases, the quotas can meet your business requirements. If you want to increase the quotas in special scenarios, contact ApsaraMQ for RocketMQ technical support.
Item | Limit | Description | |
Subscription and pay-as-you-go instances | Serverless instances | ||
Instances in a single region | The total number of created instances of all types cannot exceed 1,000 in a 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. | Adaptive elasticity is supported. | 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. | You are charged based on the number of topics that you create. For more information, see Topic fees. | 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. | 5,000 | To ensure business security and stability, we recommend that you use different instances to process different workloads. |
Message retention period |
|
| 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. | 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. |
Limits on operations
ApsaraMQ for RocketMQ is a fully managed and O&M-free Platform as a Service (PaaS) service that is based on open source Apache RocketMQ. Limits are imposed on specific high-risk O&M operations and features. If you want to increase the upper limits of the operations and features, contact ApsaraMQ for RocketMQ technical support.
Item | Limits |
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. |
Limits on instance specifications
Standard Edition instances and Professional Edition Standalone instances do not support the scaling of computing resources. We recommend that you plan your resource usage to prevent instance throttling caused by traffic that exceeds the specification limit.
The topic and consumer group quotas of an instance are calculated based on actual use cases in large-scale production environments. In most cases, these quotas can meet your business requirements. We recommend that you use different topics and consumer groups for different departments and applications. Do not run all your business in one instance.
Messaging TPS is the total number of times that messages can be sent and received. Messaging TPS is calculated based on a normal message whose size is 4 KB. Multiples must be used when you calculate the TPS for featured messages and large messages. For information about the calculation methods, see Computing specifications.
The following items describe what happens if the actual messaging TPS exceeds the specification limit:
If you enable the elastic TPS feature for an instance and the excess TPS that you use does not exceed the upper limit that is specified by the elastic TPS feature, the instance runs as expected. You are charged for the excess TPS based on a pay-as-you-go basis. If the excess TPS that you use exceeds the upper limit that is specified by the elastic TPS feature, the instance is throttled.
For information about the billing rules of the elastic TPS feature, see Elastic TPS fee.
If the elastic TPS feature is not supported by or enabled for an ApsaraMQ for RocketMQ instance, the instance is throttled.
If a large number of clients are connected to an ApsaraMQ for RocketMQ instance, the broker consumes a large number of resources to maintain the connections. This compromises the stability of the broker. We recommend that the number of connections to an ApsaraMQ for RocketMQ instance does not exceed the specification limit.
Subscription and pay-as-you-go instances
Standard Edition
Sub-category edition | Computing specification | Maximum messaging TPS | Maximum elastic TPS | Maximum connections | Outbound Internet bandwidth (Mbit/s) | Free topic quota | Maximum topic quota | Maximum group quota |
Standalone Edition | rmq.s1.micro | 500 | N/A Elastic TPS is not supported. | 2,000 | 1 to 1,000 Custom configurations are supported. | 100 | 100 | 1,000 |
Cluster High-availability Edition | rmq.s2.2xlarge | 2,000 | 4,000 | 300 | ||||
rmq.s2.4xlarge | 4,000 | 4,000 | ||||||
rmq.s2.6xlarge | 6,000 | 6,000 | 500 |
If the topic and consumer group quotas provided by the largest specification (rmq.s2.6xlarge) do not meet your requirements, we recommend that you upgrade your instance to Professional Edition and select a specification that meets your business requirements.
Professional Edition
Sub-category edition | Computing specification | Maximum messaging TPS | Maximum elastic TPS | Maximum connections | Outbound Internet bandwidth (Mbit/s) | Free topic quota | Maximum topic quota | Maximum group quota |
Standalone Edition | rmq.p1.micro | 500 | N/A Elastic TPS is not supported. | 2,000 | 1 to 1,000 Custom configurations are supported. | 150 | 150 | 1,500 |
Cluster High-availability Edition | rmq.p2.4xlarge | 4,000 | 2,000 | 4,000 | 500 | 2,000 | ||
rmq.p2.6xlarge | 6,000 | 3,000 | 6,000 | |||||
rmq.p2.10xlarge | 10,000 | 5,000 | 10,000 | 1,000 | ||||
rmq.p2.20xlarge | 20,000 | 10,000 | 10,000 | |||||
rmq.p2.50xlarge | 50,000 | 20,000 | 14,000 | 2,000 | ||||
rmq.p2.100xlarge | 100,000 | 30,000 | 26,000 | |||||
rmq.p2.150xlarge | 150,000 | 50,000 | 38,000 |
If the topic and consumer group quotas provided by the largest specification (rmq.p2.10xlarge or above) do not meet your requirements, submit a ticket.
Enterprise Platinum Edition
Sub-category edition | Computing specification | Maximum messaging TPS | Maximum elastic TPS | Maximum connections | Outbound Internet bandwidth (Mbit/s) | Free topic quota | Maximum topic quota | Maximum group quota |
Cluster High-availability Edition | rmq.u2.10xlarge | 10,000 | 5,000 | 10,000 | 1 to 1,000 Custom configurations are supported. | 200 | 3,000 | 4,000 |
rmq.u2.20xlarge | 20,000 | 10,000 | 10,000 | |||||
rmq.u2.40xlarge | 40,000 | 20,000 | 10,000 | |||||
rmq.u2.100xlarge | 100,000 | 30,000 | 26,000 | |||||
rmq.u2.150xlarge | 150,000 | 50,000 | 38,000 | |||||
rmq.u2.200xlarge | 200,000 | 60,000 | 50,000 | |||||
rmq.u2.400xlarge | 400,000 | 100,000 | 54,000 | |||||
rmq.u2.600xlarge | 600,000 | 200,000 | 80,000 | |||||
rmq.u2.1000xlarge | 1,000,000 | 300,000 | 134,000 |
If the topic and consumer group quotas provided by Enterprise Platinum Edition instances do not meet your requirements, submit a ticket.
Serverless instances
Primary instance edition | Computing specification | Peak messaging TPS | Maximum connections | Internet traffic | Maximum topic quota | Maximum group quota |
Standard Edition | rmq.s3.nxlarge | 50,000 | 10,000 | No limit is imposed. You are charged based on your actual usage. | 5,000 | 5,000 |
Professional Edition | rmq.p3.nxlarge | 50,000 If the messaging TPS exceeds 50,000, automatic scaling within minutes is supported. | 30,000 | No limit is imposed. You are charged based on your actual usage. | 5,000 | 5,000 |