All Products
Search
Document Center

ApsaraMQ for RocketMQ:Quotas and limits

Last Updated:Dec 25, 2024

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

  • 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 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

  • 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.

Attribute names that are reserved for the system

  • TRACE_ON

  • MSG_REGION

  • KEYS

  • TAGS

  • DELAY

  • RETRY_TOPIC

  • REAL_TOPIC

  • REAL_QID

  • TRAN_MSG

  • PGROUP

  • MIN_OFFSET

  • MAX_OFFSET

  • BUYER_ID

  • ORIGIN_MESSAGE_ID

  • TRANSFER_FLAG

  • CORRECTION_FLAG

  • MQ2_FLAG

  • RECONSUME_TIME

  • UNIQ_KEY

  • MAX_RECONSUME_TIMES

  • CONSUME_START_TIME

  • POP_CK

  • POP_CK_OFFSET

  • 1ST_POP_TIME

  • TRAN_PREPARED_QUEUE_OFFSET

  • DUP_INFO

  • EXTEND_UNIQ_INFO

  • INSTANCE_ID

  • CORRELATION_ID

  • REPLY_TO_CLIENT

  • TTL

  • ARRIVE_TIME

  • PUSH_REPLY_TIME

  • CLUSTER

  • MSG_TYPE

  • INNER_MULTI_QUEUE_OFFSET

  • _BORNHOST

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.

Batch message sending

Not supported.

ApsaraMQ for RocketMQ does not allow you to send messages in batches.

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

  • 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.

We recommend that you specify the interval for sending scheduled messages by hour to prevent the interval from being excessively 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

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 excessively 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.

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 instance

Serverless instance

Number of instances in a single region

The total number of created instances of all types cannot exceed 1,000 in a region.

None.

Messaging transactions per second (TPS) of a single instance

The 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.

Number of 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.

Number of 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.

Maximum value: 5000.

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.

  • 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.

Number of inflight messages in a single consumer group

Maximum value: 2500.

Maximum value: 2,500.

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

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.

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 (no longer sold)

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

Note

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 (no longer sold)

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

Note

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

Note

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