ApsaraMQ for RocketMQ has limits and specifications for instance resources, instance types, and related parameters. You must adhere to these limits when you use ApsaraMQ for RocketMQ to prevent application errors.
Parameter limits
The limits for the following parameters cannot be adjusted. You must follow these specifications when you configure parameters to prevent system processing errors that are caused by special characters or values that exceed the length limits.
Parameter | Limit | Description |
Instance name |
| None. |
Topic name |
Reserved characters: Do not use the following reserved characters or characters with special prefixes or suffixes for topic names. | Use short and common characters for topic names. Avoid special characters because they can cause parsing errors. Excessively long names may cause message sending and receiving to be rejected. |
LiteTopic name |
| Use short and common characters for LiteTopic names. Avoid special characters because they can cause parsing errors. Excessively long names may cause message sending and receiving to be rejected. |
LiteTopic expiration time |
| The expiration time for LiteTopic resources under the current topic. If no new messages are written to a LiteTopic for a period that is longer than this expiration time, the LiteTopic expires and is automatically deleted. A value of -1 indicates that the LiteTopic never expires. You can set this field when the message type is Lite. |
Consumer group name |
Reserved characters: Do not use the following reserved characters or characters with special prefixes for consumer group names. | None. |
Instance remarks |
| None. |
Topic remarks | ||
Group remarks | ||
ACL Credentials |
| None. |
Request timeout |
| The request timeout is the waiting period for synchronous calls on the client. You should set a reasonable value based on your application to avoid long thread-blocking periods. |
Message size | A maximum of 4 MB. The calculation is based on the message body size, excluding message compression. | You should compress messages and control payload sizes whenever possible. Avoid large file transfers. If a message exceeds this limit, you can split the message or store it in OSS and transmit the URL in the message. |
Custom message properties |
Reserved properties: Do not use the following reserved properties as keys for custom properties. | None. |
MessageGroup |
| MessageGroup is the group identifier for ordered messages. It is typically set to an identifier for a group of messages that must be processed in order, such as an order ID or user ID. |
Message sending retries |
| Message sending retries are handled by a built-in retry policy in the client software development kit (SDK) and are not visible to the application. Do not set this value too high because this can block business threads. You can implement a fallback mechanism in your application to ensure message reliability if a message fails to send after the maximum number of retries. |
Batch message sending | Not supported | ApsaraMQ for RocketMQ does not support sending messages in batches. |
Message consumption retries |
| Set a reasonable value as needed. Avoid using retries to trigger infinite loops because an excessive number of retries can cause a sharp increase in system pressure. |
Transaction health check interval |
| The transaction health check interval specifies the interval at which the producer client performs a transaction resolution check. This check is for half-transactional messages that were not committed because of a system restart or an error. Do not set the interval to a small value. Frequent check calls can negatively affect system performance. |
First check time for half-transactional messages |
| None. |
Maximum timeout for half-transactional messages |
| If a half-transactional message is not committed because of a system restart or an error, the producer client performs a check at the specified transaction health check interval. If no result is returned after the maximum timeout period for half-transactional messages, the message is forcibly rolled back. You can monitor this metric to prevent transaction errors. |
Maximum delay for scheduled messages |
| We recommend that you set the delay interval for scheduled messages in hours and avoid long delays. |
PushConsumer consumption timeout |
| The PushConsumer consumption timeout is controlled by the ApsaraMQ for RocketMQ server. If a message is not processed within the timeout period, the system considers the consumption to have failed and retries delivery. This may result in a small number of duplicate messages. |
PushConsumer local cache |
| When you use a PushConsumer, the client SDK caches some messages locally to improve consumer throughput and performance. You must set the number and size of cached messages within the memory limits of your system. |
PushConsumer retry interval |
| None. |
PushConsumer concurrent consumption |
| None. |
Maximum batch size for message retrieval |
| The maximum number of messages that a consumer can retrieve from the server at a time. You should set a reasonable value as needed. If you retrieve many messages at a time, many duplicate messages may be generated if consumption fails. |
SimpleConsumer maximum invisibility duration |
| The invisibility duration is the total time for message processing plus the retry interval after a failure. You should set this duration to be slightly longer than the time required for processing. |
Consumer long polling timeout | Value range: Minimum 5 seconds, maximum 20 seconds. You can customize the value within this range. | After you set the long polling timeout, if no messages are ready on the server, the client request is blocked until a new message arrives or the timeout period elapses. Using long polling for consumers can significantly reduce empty and invalid requests when the message volume is low. This reduces the pressure on both the client and the server. |
Subscription relationship | Filter expression length limit: 4,000 characters (including TAG filtering and SQL filtering). | For more information about subscription relationships, see Subscription. |
Resource quotas
ApsaraMQ for RocketMQ limits metrics such as queries per second (QPS) and concurrency for certain operations based on production environment stability and operational experience. These quotas are sufficient for most scenarios. If the quotas provided by ApsaraMQ for RocketMQ do not meet your business requirements in specific scenarios, you can contact ApsaraMQ for RocketMQ technical support for assistance.
Limit item | Limit | Description | |
Subscription and pay-as-you-go instances | Serverless instances | ||
Instances per region | A maximum of 1,000 instances of all types. | None. | |
Message sending and receiving TPS per instance | Determined by the purchased instance type. For more information about specific limits, see Instance type limits. | Elastic and adaptive | The message sending and receiving TPS reflects the processing performance of the current instance. If the actual TPS exceeds the limit for your instance type, throttling is triggered. In this case, you must upgrade your instance type. |
Message retention period |
|
| We recommend that you extend the retention period as long as storage costs are manageable. A longer retention period provides a larger window for troubleshooting and data backtracing. |
Number of inflight messages per consumer group | A maximum of 2,500. | A maximum of 2,500. | Too many inflight messages can slow down the consumer response. You should monitor this metric and investigate the cause if the value is too high. |
Number of LiteTopics a single consumer can subscribe to | A maximum of 2,000. | A maximum of 2,000. | Subscribing a single consumer to too many LiteTopics may affect client performance. You can submit a ticket to increase this limit if needed. |
Maximum consumption TPS per LiteTopic | 200 | 200 | You can create hundreds of thousands to millions of LiteTopics under a single topic. The total consumption TPS of the topic is not affected. |
Operation limits
ApsaraMQ for RocketMQ is a fully managed Platform as a Service (PaaS) that requires no O&M. Therefore, the system restricts some high-risk operations and features that are available in the open-source Apache RocketMQ. If you have special requirements, you can contact ApsaraMQ for RocketMQ technical support for assistance.
Limit item | Description |
Compatibility with Apache RocketMQ Admin tools | ApsaraMQ for RocketMQ does not support using the Apache RocketMQ Admin API or command-line interface (CLI) to manage instances, topics, or group resources. To manage resources using an API, use the OpenAPI provided by Alibaba Cloud. The Alibaba Cloud OpenAPI supports multi-language SDKs and CLI commands. |
Apache RocketMQ Request-Reply messages | ApsaraMQ for RocketMQ does not support sending Apache RocketMQ Request-Reply messages. |
Apache RocketMQ Streaming component | ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ Streaming component. You can deploy it yourself in your Alibaba Cloud environment or use the Data Integration feature of ApsaraMQ for RocketMQ for lightweight data integration and computing. |
Apache RocketMQ MQTT component | ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ MQTT component. We recommend that you use the ApsaraMQ for MQTT service provided by Alibaba Cloud, which provides more complete features. |
Apache RocketMQ EventBridge component | ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ EventBridge component. We recommend that you use the Alibaba Cloud EventBridge service, which provides more complete features. |
Apache RocketMQ-Connector component | ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ-Connector component. You can use the Data Integration feature of ApsaraMQ for RocketMQ to stream data in and out of the message queue. |
Instance type limits
All instance types in the Standard Edition series and the Single Node Edition instance types in the Professional Edition series do not support burst elastic computing. You should plan your resource usage in advance to prevent traffic bursts during peak periods from exceeding instance type limits and causing throttling.
The topic and group quotas for a single instance are calculated based on large-scale production environment practices and meet the business requirements of most scenarios. We recommend that you split and isolate your services by department and domain into separate instances. You should avoid running all your services on a single instance.
The message sending and receiving TPS is calculated based on the total number of normal messages that are 4 KB in size. When you use advanced message features or send large messages, a multiplier is applied to the calculation. For more information about the calculation method, see Calculation specifications.
If the actual TPS for message sending and receiving exceeds the upper limit of your purchased instance type:
If elastic TPS is enabled for the instance, the instance can run normally within the range of [Base Specification, Elastic Specification], and you are charged for the elastic TPS on a pay-as-you-go basis. If the elastic capacity is exceeded, the instance is still throttled.
For information about how elastic TPS is billed for non-Serverless instances, see Elastic TPS fees. For information about how elastic TPS is billed for Serverless instances, see Serverless elastic TPS fees.
If an instance does not support or has not enabled the elastic TPS feature, ApsaraMQ for RocketMQ throttles the instance.
If there are too many connections between clients and an ApsaraMQ for RocketMQ instance, the server consumes significant resources to maintain these connections, which can severely affect server stability. Therefore, you must ensure that the number of client connections does not exceed the limit for your instance type.
Serverless instances
Concurrent online clients: The number of online producer or consumer objects. One producer or one consumer object counts as one client.
Resource count: The total number of topics and consumer groups.
Deployment architecture | Capacity model | TPS specification | Maximum concurrent online clients | Free quota for concurrent online clients | Maximum resource count | Free quota for resource count | Maximum number of LiteTopics that can be created or subscribed to |
Shared | Cumulative | All | 5,000 | 500 | 3,000 | 100 | / |
Reserved + Elastic | [2000, 20,000] | 5,000 | 1,000 | 3,000 | 200 | ||
(20,000, 50,000] | 8,000 | 2,000 | 3,000 | 200 | |||
(50,000, 100,000] | 10,000 | 3,000 | 3,000 | 200 | |||
(100,000, 200,000] | 20,000 | 5,000 | 3,000 | 200 | |||
Dedicated | Reserved + Elastic | 5,000 | 3,000 | 2,000 | 3,000 | 300 | 300,000 |
10,000 | 6,000 | 4,000 | 4,000 | 300 | 600,000 | ||
15,000 | 8,000 | 6,000 | 6,000 | 500 | 720,000 | ||
[20,000, 50,000] | 10,000 | 8,000 | 6,000 | 500 | 1,000,000 | ||
(50,000, 100,000] | 20,000 | 10,000 | 6,000 | 500 | 1,500,000 | ||
(100,000, 200,000] | 40,000 | 20,000 | 8,000 | 1,000 | 2,400,000 | ||
(200,000, 300,000] | 80,000 | 40,000 | 10,000 | 1,500 | 4,700,000 | ||
(300,000, 500,000] | 100,000 | 50,000 | 16,000 | 2,000 | 6,300,000 | ||
(500,000, 1,000,000] | 200,000 | 100,000 | 40,000 | 3,000 | 11,600,000 |
Non-Serverless (subscription and pay-as-you-go) instances
Standard Edition instance types
Instance sub-series | Instance type | Base TPS limit for message sending and receiving (TPS) | Burst (elastic) TPS limit for message sending and receiving (TPS) | Maximum connections | Downstream Internet bandwidth (Mbps) | Free topic quota | Maximum topic quota | Maximum consumer group quota | Maximum number of LiteTopics that can be created or subscribed to |
Single Node Edition (Discontinued) | rmq.s1.micro | 500 | Not applicable This instance type does not support burst elasticity. | 2,000 | 1 to 1,000 Custom configuration is supported. | 100 | 100 | 1,000 | / |
High-availability Cluster Edition | rmq.s2.2xlarge | 2,000 | 4,000 | 300 | 150,000 | ||||
rmq.s2.4xlarge | 4,000 | 4,000 | 250,000 | ||||||
rmq.s2.6xlarge | 6,000 | 6,000 | 500 | 300,000 |
If the highest specification for topics and consumer groups in the Standard Edition (rmq.s2.6xlarge) still cannot meet your business requirements, we recommend that you upgrade to the Professional Edition and select a suitable instance type.
Professional Edition instance types
Instance sub-series | Instance type | Base TPS limit for message sending and receiving (TPS) | Burst (elastic) TPS limit for message sending and receiving (TPS) | Maximum connections | Downstream Internet bandwidth (Mbps) | Free topic quota | Maximum topic quota | Maximum consumer group quota | Maximum number of LiteTopics that can be created or subscribed to |
Single Node Edition (Discontinued) | rmq.p1.micro | 500 | Not applicable This instance type does not support burst elasticity. | 2,000 | 1 to 1,000 Custom configuration is supported. | 150 | 150 | 1,500 | / |
High-availability Cluster Edition | rmq.p2.2xlarge | 2,000 | 1,000 | 4,000 | 500 | 2,000 | 150,000 | ||
rmq.p2.4xlarge | 4,000 | 2,000 | 4,000 | 250,000 | |||||
rmq.p2.6xlarge | 6,000 | 3,000 | 6,000 | 300,000 | |||||
rmq.p2.10xlarge | 10,000 | 5,000 | 10,000 | 1,000 | 600,000 | ||||
rmq.p2.20xlarge | 20,000 | 10,000 | 10,000 | 800,000 | |||||
rmq.p2.30xlarge | 30,000 | 15,000 | 12,000 | 2,000 | 1,000,000 | ||||
rmq.p2.40xlarge | 40,000 | 20,000 | 12,000 | 1.2 million | |||||
rmq.p2.50xlarge | 50,000 | 20,000 | 14,000 | 1.4 million | |||||
rmq.p2.100xlarge | 100,000 | 30,000 | 26,000 | 2,200,000 | |||||
rmq.p2.120xlarge | 120,000 | 40,000 | 30,000 | 2,700,000 | |||||
rmq.p2.150xlarge | 150,000 | 50,000 | 38,000 | 3,300,000 | |||||
rmq.p2.200xlarge | 200,000 | 60,000 | 50,000 | 4,500,000 |
If the highest specification for topics and consumer groups in the Professional Edition (rmq.p2.10xlarge or higher) still cannot meet your business requirements, submit a ticket for assistance.
Platinum Edition instance types
Instance sub-series | Instance type | Base TPS limit for message sending and receiving (TPS) | Burst (elastic) TPS limit for message sending and receiving (TPS) | Maximum connections | Downstream Internet bandwidth (Mbps) | Free topic quota | Maximum topic quota | Maximum consumer group quota | Maximum number of LiteTopics that can be created or subscribed to |
High-availability Cluster Edition | rmq.u2.10xlarge | 10,000 | 5,000 | 10,000 | 1 to 1,000 Custom configuration is supported. | 200 | 3,000 | 4,000 | 600,000 |
rmq.u2.20xlarge | 20,000 | 10,000 | 10,000 | 800,000 | |||||
rmq.u2.30xlarge | 30,000 | 15,000 | 12,000 | 1,000,000 | |||||
rmq.u2.40xlarge | 40,000 | 20,000 | 10,000 | 1,200,000 | |||||
rmq.u2.50xlarge | 50,000 | 20,000 | 14,000 | 1,400,000 | |||||
rmq.u2.60xlarge | 60,000 | 22,000 | 16,000 | 1,600,000 | |||||
rmq.u2.70xlarge | 70,000 | 24,000 | 18,000 | 1,700,000 | |||||
rmq.u2.80xlarge | 80,000 | 26,000 | 20,000 | 1,800,000 | |||||
rmq.u2.90xlarge | 90,000 | 28,000 | 24,000 | 2,000,000 | |||||
rmq.u2.100xlarge | 100,000 | 30,000 | 26,000 | 2,200,000 | |||||
rmq.u2.120xlarge | 120,000 | 40,000 | 30,000 | 2,700,000 | |||||
rmq.u2.150xlarge | 150,000 | 50,000 | 38,000 | 3,300,000 | |||||
rmq.u2.200xlarge | 200,000 | 60,000 | 50,000 | 4,500,000 | |||||
rmq.u2.250xlarge | 250,000 | 70,000 | 51,000 | 5,600,000 | |||||
rmq.u2.300xlarge | 300,000 | 80,000 | 52,000 | 6,300,000 | |||||
rmq.u2.350xlarge | 350,000 | 90,000 | 53,000 | 7,500,000 | |||||
rmq.u2.400xlarge | 400,000 | 100,000 | 54,000 | 9,300,000 | |||||
rmq.u2.450xlarge | 450,000 | 120,000 | 60,000 | 10,400,000 | |||||
rmq.u2.500xlarge | 500,000 | 140,000 | 66,000 | 11,600,000 | |||||
rmq.u2.550xlarge | 550,000 | 160,000 | 72,000 | 12,800,000 | |||||
rmq.u2.600xlarge | 600,000 | 200,000 | 80,000 | 14,000,000 | |||||
rmq.u2.1000xlarge | 1,000,000 | 300,000 | 134,000 | 23,200,000 |
If the specifications for topics and consumer groups in the Platinum Edition still cannot meet your business requirements, submit a ticket for assistance.