Docs

Message Queue for RocketMQ

Best Practices

Deploy RocketMQ instances across availability zones

Deploying across availability zones improves instance availability. This document explains how cross-availability zone deployment affects your instances.

Note

Before creating a RocketMQ instance deployed across availability zones, address the following requirements:

Deploy the RocketMQ client ECS and RocketMQ instances in the same availability zone whenever possible to avoid asymmetric fault domains.

Instances deployed across availability zones may have network latency of 2ms to 3ms. Evaluate if the increase in single-request latency affects your business.

If the client calls interfaces synchronously, the instance's throughput performance may decrease. Consider reserving extra performance capacity, upgrading to a higher computing specification, or switching to asynchronous interface calls.

Configure cross-availability zone deployment

Message Queue for RocketMQ supports deploying RocketMQ instances across multiple availability zones, enabling multiple AZs. Instances deployed across availability zones provide stronger disaster recovery, ensuring Cluster data reliability and service availability on all fronts. To enable cross-availability zone disaster recovery, set the deploy method to cross-availability zone deployment and select 3 availability zones when purchasing a RocketMQ instance. After you create an instance, you cannot change its deploy method. For example, an instance deployed in a single availability zone cannot switch to cross-availability zone deployment. Instances deployed across availability zones have no difference for the client in terms of usage. We recommend also distributing client machines across the same multiple availability zones as the server to increase overall service availability and prevent failures in isolated availability zone scenarios. For purchased RocketMQ instances, you can find the availability zone row in the Basic Information section on the Instance Details tab of the RocketMQ instance, and check the number of availability zones. If the number of availability zones is greater than 1, the instance is deployed across multiple availability zones.

Availability and fault domains

When instances are deployed across availability zones, underlying resources such as network, compute nodes, and storage nodes are distributed across multiple availability zones. Faults are isolated between availability zones, so failures in the underlying resources of one availability zone do not affect the nodes in other availability zones. If there is a failure in compute, storage, or other resources within an availability zone, the cluster can switch to other availability zones internally to ensure business continuity. If more than one availability zone fails, availability issues may still occur. If there is a network failure between two availability zones, meaning the network between zones is down, data can still be written normally, but the synchronization progress of replica data may be affected.

Performance impact

In cross-availability zone deployment scenarios, data, including replicas, is distributed across multiple availability zones. The data request path also spans multiple availability zones by default, rather than being “zone-affinitized.” Network latency between availability zones typically ranges from 0.5 to 1 ms, which is slightly higher than within a single zone. Therefore, cross-availability zone deployment could increase request latency and replica synchronization duration. In RocketMQ instances, data is automatically synchronized to replicas, so compared to deployment in a single availability zone, maximum throughput capacity may be somewhat reduced. Typically, synchronous transmission results in less than 20% performance loss, while asynchronous transmission causes less than 10% loss.

Last updated: 2026.02.09 14:40:42