Docs

Message Queue for RocketMQ

Best Practices

RocketMQ instance adaptation scenarios

If the current metrics of your Message Queue for RocketMQ instance exceed the specification limits, or the cluster running load exceeds the recommended upper limit, rate limiting may be triggered. Monitor the specifications and metrics of the instance, and adjust instance specifications before rate limiting is triggered. This document describes typical business scenarios where instance specification adjustment is required.

Scenarios requiring upgrade of instance specifications

Upgrading the compute specification involves adjusting the compute resources for RocketMQ instances. Increasing the compute specification can improve instance throughput and reduce request latency. We recommend evaluating the following metrics to determine whether to upgrade the compute specification for your RocketMQ instance. If any of the following conditions are met, consider upgrading the specification.

Instance throughput is close to the maximum specification limit

Different compute specifications of RocketMQ instances have varying TPS limits, with these limits based on 4KiB message sizes. Message sizes vary significantly across different business scenarios, so TPS alone cannot indicate whether throughput has reached its limit. We recommend estimating your overall business traffic against the instance’s throughput limit using total bandwidth for production and consumption.

We recommend upgrading the instance when the total bandwidth used in your business reaches 85% of the instance’s maximum bandwidth. The components are:

Instance bandwidth limit: Estimated as recommended TPS limit × 4KiB.

Total business bandwidth used: Production throughput rate + consumption throughput rate. You can view production traffic rate and consumption traffic rate on the Cloud Monitor tab of your RocketMQ instance For detailed instructions, refer to View Monitoring Data.

Request latency increases or failure rate rises

As your business grows and TPS increases, if production and consumption requests start to show significant latency or message production begins to fail due to flow control limits, we recommend upgrading your instance Observe using the following methods:

Monitor changes in request latency We recommend viewing the P99 message production duration and P99 message consumption duration metrics on the Cloud Monitor tab of your instance. Since average latency depends on your business message size, you can observe trends in these metrics to determine if an instance upgrade is needed.

Monitor changes in the failed message write rate If this metric consistently shows a nonzero value and your client logs report “broker busy, start flow control for a while,” it means the broker has reached its bottleneck and started flow control.

You can view P99 message production duration, P99 message consumption duration, and failed message write rate on the Cloud Monitor tab of your RocketMQ instance For details, refer to View monitoring data.

Consider whether there are business traffic peaks.

One scenario for RocketMQ is peak shaving and valley filling. If short-term peaks cause the above situation, decide whether to upgrade the instance based on business latency tolerance and whether these peaks have a real impact.

Scenarios requiring storage expansion

When RocketMQ disk usage reaches 75%, it triggers message deletion to reclaim disk space. Messages may be deleted before reaching their expiration time. If your business needs to ensure message retention time, we recommend expanding disk space when disk usage approaches 75%.

For instances requiring guaranteed message retention periods, estimate the needed storage using the following method:

Average instance production TPS × average message size (GiB) × message retention period (seconds) × 3 (replica count) ÷ 75% (disk usage threshold)

Average instance write throughput (GiB) × message retention period (seconds) × 3 (replica count) ÷ 75% (disk usage threshold)

tip

Changing specifications affects the number of backend service nodes. We recommend enabling Automatic queue expansion during the upgrade. The backend service will automatically create queues for all topics of the instance on the newly expanded service nodes, eliminating the need for manual configuration.

If your business requires keeping the number of queues unchanged, or if changes to Topic queues require business adaptation, you can disable automatic queue scaling.

Alarm strategies for specific scenarios

To prevent a surge in business traffic from quickly filling disk space and exceeding instance specifications, which may trigger various flow control restrictions, we recommend setting up alarm strategies for certain monitoring items to track your instance's status. Once an alarm is created, you do not need to constantly monitor every instance metric. You only need to assess whether an upgrade is needed based on the above scenario determination when the alarm is triggered.

The recommended alarm strategies for upgrade scenarios are listed below. You may set the duration based on the typical peak duration in your business. We suggest triggering alarms if thresholds are exceeded for more than one cycle. For detailed configuration and threshold settings, refer to the recommended alarm rules.

Scenario	Monitoring metrics	description
Upgrade computing specifications	Instance total production and consumption rate	We recommend configuring a maximum alarm. The threshold can be estimated according to the method recommended in Instance throughput approaches specification limits.
		Instance production and consumption rate	Recommend alarm for maximum configuration value, and estimate the threshold based on the method in Instance throughput approaching specification limits.
		Message production P99 time	Recommend alarm for maximum configuration value. Actual duration and business message size may vary; you can set the threshold at twice the value during steady-state operation.
		Message write failure rate	Maximum value alarm; configuring the alarm to trigger when the value is greater than 0 is recommended.
Storage expansion	Instance disk usage rate	The alarm triggers when the maximum threshold of 75% is reached, and the monitored value remains above the threshold for one cycle.

Last updated: 2026.02.09 14:40:42