ApsaraMQ for RabbitMQ provides a highly available, RabbitMQ-compatible messaging service that supports the AMQP 0-9-1 protocol. The product SLA guarantees platform-side service availability, which is not equivalent to 100% end-to-end availability for your business.
Product SLA and business availability
According to the official ApsaraMQ for RabbitMQ Service Level Agreement, service availability is measured per instance on a per-calendar-month basis. The baseline commitment in the current agreement is no less than 99.95%. Based on a 30-day calendar month, 99.95% corresponds to approximately 21.6 minutes of unavailability as defined by the agreement. This value illustrates the SLA metric only and does not define the acceptable failure window for your business. Actual calculations are subject to the service unavailability definitions, exclusions, and the agreement in effect at the time of purchase.
Business availability is also affected by client reconnection, network and DNS conditions, application deployment, consumption processing capacity, idempotent processing capabilities, cross-region disasters, version lifecycle, and customer-specific configurations. If your business continuity objective exceeds the SLA of a single instance, you must build multi-instance, multi-region, failover, and message idempotence capabilities on both the application side and the resource architecture side.
SLA metrics may vary by instance type or specification. Specific entitlements are subject to the purchase page, the Alibaba Cloud official website, and the agreement in effect at the time of purchase. A multi-instance solution does not create a new product SLA, nor can you multiply the SLAs of two instances. Business availability depends on fault isolation, message synchronization, client failover, and the effectiveness of drills.
Architecture boundaries
ApsaraMQ for RabbitMQ is compatible with the AMQP 0-9-1 protocol and uses a managed multi-node architecture on the server side. Access methods such as public endpoint, VPC, and PrivateLink private network connection access point are subject to the console and official documentation.
ApsaraMQ for RabbitMQ improves instance availability through multi-node and multi-zone capabilities. The server side uses multiple nodes to handle connections and requests. When a single server-side node or zone experiences an anomaly, multi-node capabilities help reduce the impact on instance availability. Specific capabilities are subject to the instance type, region, and purchase page.
Client connections are handled at the Connection granularity. Establishing multiple long-lived Connections distributes traffic more evenly across multiple nodes but does not guarantee that each Connection lands on a different node. Creating multiple Channels on a single AMQP Connection improves concurrent multiplexing within that Connection but cannot replace Connection-level server-side node distribution. For high-concurrency or mission-critical workloads, establish multiple long-lived Connections and distribute producers and consumers across the connection pool to avoid concentrating all traffic on a single or a few Connections.
The following scenarios are not addressed by a single-instance architecture:
Region-level failures, cross-region network failures, or customer-side VPC, DNS, or security group anomalies
Clients that have not configured automatic reconnection, Channel rebuilding, or consumer resubscription
Clients that use only a few long-lived Connections, causing traffic to be insufficiently distributed across server-side nodes
Slow consumer processing, business processing failures, message backlog, or throttling due to exceeded quotas
Lack of idempotent processing, causing duplicate consumption, out-of-order delivery, or business side effects during failover or replay
Client-side improvements
Regardless of which deployment solution you select, verify that your client implementation meets the following requirements. For complete guidance, see SDK usage notes and best practices for using a Spring Boot client.
Automatic reconnection — Automatically rebuild the Connection after disconnection. Depending on the SDK you use, verify the topology and consumer recovery capabilities. For more information, see Configure automatic reconnection for a client.
Multiple Connections for traffic distribution — Configure multiple long-lived Connections based on your production and consumption concurrency and the instance Connection quota. Use separate Connections for producing and consuming. Do not concentrate all production and consumption on a single Connection, and do not frequently create and close Connections. For general recommendations, see Connections and channels. For Spring clients, see best practices for using a Spring Boot client.
Channel rebuilding — RabbitMQ Channels are not permanent resources. If protocol exceptions, resource declaration conflicts, or throttling occur, rebuild the Channel. For resource declaration conflicts, correct the declaration parameters first. For throttling scenarios, apply backoff and load shedding before rebuilding to avoid creating rebuild loops. Channels can reuse Connections but cannot replace Connection-level server-side node distribution. For more information, see best practices for instance throttling.
Consumer recovery — After reconnection, re-establish consumer subscriptions by restoring
basic.consumeand consumer callbacks. Verify that the recovery behavior of exclusive Queues, Consumer Tags, and other resources after reconnection meets your expectations.Publisher Confirm — Use Publisher Confirm on the production side to determine whether the server has received and assumed responsibility for the message. Publisher Confirm does not mean that the consumer has processed the message. When confirmation times out or is not acknowledged, retry with the same business message ID following idempotent rules.
Consumer ACK and retry — ACK only after successful business processing. On failure, execute reject, nack, limited-count retry, or route to a dead letter queue based on your business strategy. Avoid infinite requeue that creates retry loops.
Idempotent processing — Production, routing, failover, and replay can all produce duplicate messages. The producer should maintain a stable business message ID for the same business message, and the consumer must de-duplicate by business ID. For more information, see Message idempotence.
Throttling and circuit breaking — When the instance is abnormal or downstream is unhealthy, the producer should throttle and apply backoff with upper limits on retries to avoid retry amplification, backlog, and cascading failures. For more information, see best practices for instance throttling.
Access address refresh — If you switch instances through a configuration center or customer-managed domain names, the client must support refreshing the access address to avoid holding stale addresses indefinitely. When using customer-managed domain names, verify DNS TTL, client or JVM DNS caching, and TLS hostname verification behavior.
Recommended solutions
The following sections describe four deployment solutions at increasing availability tiers. The following table summarizes each solution to help you identify the right fit for your workload. In addition to the solution-specific considerations, verify that your client meets the requirements described in Client-side improvements.
For workloads that require higher stability, resource isolation, or capacity predictability, select the Platinum Edition or the Serverless Exclusive Edition. Specific capabilities and SLA terms are subject to the instance type description and the purchase page.
Solution | Applicable scope | Key prerequisites | Key limitation |
Single-instance baseline | Non-critical paths with relaxed RTO/RPO requirements | Client reconnection, monitoring, and alerting | Platform SLA of the instance type only |
Same-region dual-instance standby | Core workloads that need instance-level failure recovery within the same region | Configuration center, message synchronization, and idempotent processing | Does not replace cross-region disaster recovery |
Cross-region primary-standby | Workloads that need protection against region-level failures | Cross-region instances, message routing, and defined RTO/RPO and switchback conditions | No transparent failover by default |
Active-active | Workloads with mature idempotent processing, deduplication, and conflict resolution | Global message IDs, deduplication, and conflict resolution strategies | Not recommended as the default solution |
Single-instance baseline solution
This solution applies to non-critical paths, workloads that can tolerate short unavailability, and scenarios with relaxed RTO and RPO requirements.
Key design considerations
Based on instance types and limits, select an instance specification that meets your business requirements for TPS, Queues, Connections, message size, and retention period.
Enable automatic Connection reconnection on the client, and ensure the client has Channel rebuilding and consumer recovery capabilities.
Establish multiple long-lived AMQP Connections per application instance based on business concurrency, and distribute production and consumption traffic through a connection pool. Do not carry all traffic on a single Connection and then only increase the number of Channels.
Configure Publisher Confirm, consumer ACK, timeout retry, dead letter queues, and alerts.
Complete instance version upgrades as required by the official version management policy and upgrade notifications. Do not run expired or end-of-maintenance versions for extended periods.
Configure alerts for key metrics including connection count, send and consume throughput, error codes, Queue backlog, consumption latency, and throttling based on monitoring and alerting.
Risks and limitations
A single-instance solution provides only the product SLA corresponding to the instance type, which is not equivalent to 100% business-side availability.
If your business cannot tolerate the failure window of a single instance, upgrade to a multi-instance disaster recovery solution.
Same-region dual-instance standby solution
This solution applies to core workloads that need to improve instance-level failure recovery within the same region but do not require cross-region disaster recovery.
Architecture overview
Key design considerations
Purchase two RabbitMQ instances in the same region. A same-region dual-instance setup does not replace cross-region disaster recovery.
Keep the Vhost, Exchange, Queue, Binding, account permissions, and network access policies of the primary and standby instances functionally equivalent. (Recommended) Manage resources through automated configuration or application startup declarations to avoid configuration drift. Manage credentials for the primary and standby instances separately and rotate them according to your security policy.
Message synchronization options:
Application dual-write — The producer writes to both the primary and standby instances simultaneously. Application dual-write can reduce data gaps from single-path write failures but does not provide cross-instance atomicity guarantees. Handle partial success, confirmation timeout, idempotent retry, and compensation.
Global message routing — Use global message routing to asynchronously forward messages from a source Queue on the primary instance to a Queue or Exchange on the standby instance. This method has synchronization latency, and the RPO depends on routing backlog and network conditions. Feature support is subject to the instance type description and the console.
Global message routing consumes from the source Queue and forwards messages to the target. It is not a sidecar replication of the source Queue. Do not directly reuse a Queue that business consumers are actively consuming as the routing source. Bind the source Exchange to both a business Queue and a dedicated disaster recovery synchronization Queue, and use the dedicated Queue as the routing source. For semantics, see global message routing and RabbitMQ Shovel.
If the global message routing target type is set to Exchange, verify that the target Exchange has Queues bound to it that can store messages. Otherwise, messages routed to the Exchange may be lost if no Queue is available to receive them.
Consumers default to consuming from the primary instance only. During failover, start or scale up consumers on the standby instance and prevent both primary and standby from simultaneously consuming the same business stream to avoid duplicate side effects.
Implement idempotent processing by business message ID, allowing duplicate or compensatory delivery after failover.
Recommended failover procedure
Confirm through monitoring that the primary instance is unavailable or experiencing performance anomalies that affect business send or consume operations and has not recovered within the expected window.
Pause, throttle, or degrade production-side writes according to your business contingency plan to prevent the primary-standby data gap from widening during the failure window.
Switch to the standby instance through the configuration center or application access address configuration. If you use customer-managed DNS, verify that DNS caching and TLS verification do not block the failover.
Start consumers on the standby instance or increase the standby instance consumption weight.
Monitor send success rate, consumption rate, Queue backlog, and business success rate.
After the primary instance recovers, complete reconciliation, compensation, and deduplication based on business send and consume records, backlog metrics, and business message IDs before switching back through a controlled change process.
Cross-region primary-standby disaster recovery solution
This solution applies to core workloads that need to protect against region-level failures, or workloads that are inherently deployed across regions.
Architecture overview
Key design considerations
Create RabbitMQ instances in two separate regions. Keep the topology, account permissions, and network access policies functionally equivalent. Manage credentials separately for each instance.
Use global message routing, application dual-write, or a business Outbox mechanism to synchronize critical messages. Feature support for global message routing is subject to the instance type description and the console.
When using global message routing, apply the same dedicated disaster recovery synchronization Queue design as the same-region solution to avoid competing with business consumers for the source Queue.
If the global message routing target type is set to Exchange, verify that the target Exchange has Queues bound to it that can store messages.
When using global message routing, evaluate EventBridge and Cloud Enterprise Network (CEN) costs, message synchronization latency, and routing backlog. When using application dual-write or Outbox, plan separately for client networking, access points, whitelists, link costs, and failover approach.
The message size limit on the target must be no less than that on the source. Messages exceeding the target limit may fail to route.
Global message routing does not support transitive routing. A route from A to B to C does not automatically forward messages from A through B to C. If you need A-to-C routing, configure a direct A-to-C route.
Cross-region disaster recovery should not assume fully transparent failover by default. Clearly define the RTO, RPO, failover approvers, switchback conditions, and data compensation mechanism.
Active-active solution
This solution applies to workloads that already have strong idempotent processing, deduplication, conflict resolution, and eventual consistency capabilities, and where both regions or instances need to simultaneously handle traffic. Active-active is a customer application architecture design and does not mean the product automatically provides cross-instance active-active or global consistency capabilities.
Key design considerations
The producer must use globally unique business message IDs that remain stable during retries.
The consumer must implement idempotent processing and deduplication by business primary key. Do not rely on RabbitMQ delivery count as the sole source of truth.
Clearly define the primary write path and synchronization direction for each message to avoid bidirectional synchronization loops or duplication amplification.
Clearly define ordering semantics boundaries. Cross-instance active-active typically does not provide globally strict ordering guarantees.
Clearly define conflict resolution strategies, including duplicate payments, duplicate orders, inventory deductions, and other business side effects.
Maintain continuous drill and automated reconciliation capabilities.
Risks and limitations
Active-active is not recommended as the default solution. Most workloads should prefer primary-standby or tiered degradation to avoid stability degradation caused by complexity.
Drill and acceptance criteria
Before launching a multi-instance disaster recovery solution, complete at least the following drills:
Drill item | Verification objective |
Primary instance access failure | Client fails over to the standby instance as expected. RTO meets the target. |
Primary instance send failure | Producer identifies failures and retries or compensates without uncontrolled duplication. |
Multi-connection distribution | Application instances establish multiple long-lived Connections as configured. After restart or failover, the connection pool recovers and traffic does not remain concentrated on a single Connection. |
Consumer restart | Application rebuilds Channels and re-establishes consumer subscriptions. |
Global message routing latency | Source dedicated Queue backlog, target inflow, and synchronization latency are observable. |
Standby instance consumption takeover | Standby instance consumers process existing messages after startup. Business idempotence is effective. |
Switchback to primary instance | Business reconciliation, compensation, deduplication, and canary switchback complete successfully. |
The following metrics define acceptance criteria for your disaster recovery solution:
RTO — Time from when the business is affected or failover conditions are met until business recovery.
RPO — Maximum range of messages that may be lost or require compensation during the failure window.
Duplication rate — Percentage of duplicate messages during failover and replay and their business impact.
Backlog recovery time — Time for Queue backlog to return to normal levels after failover.
Client recovery success rate — Success rate of Connection reconnection, Channel rebuilding, and consumer resubscription.
Connection distribution — After application restart, scale-out, or failover, production and consumption traffic continues to be distributed across multiple long-lived Connections. Avoid long-term use of only a single Connection.