云消息队列 RabbitMQ 版提供高可用的 RabbitMQ 兼容服务，并兼容 AMQP 0-9-1 协议。需要注意的是，产品 SLA 保障的是平台侧服务可用性，不等同于客户业务端到端 100% 可用。
背景
根据官方 RabbitMQ 服务等级协议，RabbitMQ 服务可用性以单个实例为维度，按单个自然月计算，当前协议中的基础承诺为不低于 99.95%。以 30 天自然月估算，99.95% 对应约 21.6 分钟的协议口径不可用时间。该数值仅用于理解 SLA 指标，不等同于业务可接受的故障窗口；实际计算以协议中的服务不可用定义、除外情形及订购时生效协议为准。
业务整体可用性还受到客户端重连、网络与 DNS、应用发布、消费处理能力、幂等能力、跨地域灾害、版本生命周期和客户自身配置等因素影响。若业务连续性目标高于单实例产品 SLA，需要在应用侧和资源架构侧主动建设多实例、多地域、切换和消息幂等能力。
不同实例类型或规格的 SLA 指标可能不同，可参考实例类型，具体权益以购买页、阿里云官网和订购时生效协议为准。多实例方案不会形成新的产品 SLA，也不能将两个实例的 SLA 简单相乘；业务可用性取决于故障隔离、消息同步、客户端切换和演练效果。
架构边界
云消息队列 RabbitMQ 版对外兼容 AMQP 0-9-1 协议，服务端采用托管化多节点架构。公网、VPC 和 私网连接接入点等接入方式，以控制台和官方文档支持情况为准。
RabbitMQ 版通过多节点和多可用区能力提升实例可用性。服务端由多个节点共同承载连接和请求，单个服务端节点或可用区异常时，多节点能力有助于降低对实例可用性的影响；具体能力以实例类型、地域和购买页说明为准。
客户端连接由服务端按 Connection 粒度承载。建立多条长期 Connection 有助于让连接和流量在多个节点之间更充分分散，但不表示每条 Connection 必然落到不同节点。单个 AMQP Connection 上创建多个 Channel 只能提升该连接内的并发复用，不能替代 Connection 级别的服务端节点分散。高并发或核心业务应建立多条长期 Connection，并让生产者和消费者在连接池内分散使用，避免所有流量集中在单条或少数连接上。
但以下场景不是单实例架构天然解决的：
地域级故障、跨地域网络故障或客户侧 VPC、DNS、安全组异常。
客户端未配置自动重连、Channel 重建和消费者重新订阅。
客户端只使用极少数长期 Connection，导致连接和流量无法在服务端多个节点之间充分分散。
客户消费慢、业务处理失败、消息堆积或超配额限流。
客户未做幂等，切换或回放导致重复消费、乱序或业务副作用。
客户侧须完成的改造
无论选择哪种实例形态，建议优先按照云消息队列 RabbitMQ 版官方最佳实践完成接入和改造，完整实践可参考SDK 使用注意事项和Spring 集成最佳实践。以下为需重点确认的改造项（不限于此）：
自动重连：连接断开后自动重建 Connection，并根据所用 SDK 确认拓扑和消费者恢复能力，具体可参考客户端配置自动重连。
多 Connection 分散流量：根据生产和消费并发、实例 Connection 配额配置多条长期 Connection，并将生产和消费连接分开使用。不要把所有生产和消费都压在单条 Connection 上，也不要频繁创建和关闭 Connection。通用建议可参考Connection 和 Channel，Spring 客户端可参考Spring 集成最佳实践。
Channel 重建：RabbitMQ Channel 不是永久资源。如发生协议异常、资源声明冲突、限流等场景，需要重建 Channel。资源声明冲突应先修正声明参数，限流场景应先退避和降载，避免循环重建 Channel。Channel 可以复用 Connection，但不能替代 Connection 级别的服务端节点分散，具体可参考实例限流最佳实践。
消费者恢复：重连后重新建立消费订阅，恢复
basic.consume和消费者回调；同时确认排他 Queue、Consumer Tag 等资源在重连后的恢复行为符合预期。Publisher Confirm：生产端通过 Publisher Confirm 判断服务端是否已接收并承担消息责任。Publisher Confirm 不代表消费者已成功处理消息；确认超时或未确认时，应使用相同业务消息 ID 按幂等规则重试。
消费 ACK 和重试：业务处理成功后再 ACK；失败时按业务策略执行 reject、nack、有限次数重试或进入死信，避免无限 requeue 形成重试循环。
幂等处理：生产、路由、切换和回放都可能带来重复消息，生产端应为同一业务消息保持稳定的业务消息 ID，消费端必须按业务 ID 去重，具体可参考消息幂等。
限流与熔断：实例异常或业务下游异常时，生产端应限流并对重试设置退避和上限，避免重试放大、堆积和雪崩，具体可参考实例限流最佳实践。
接入地址刷新：如果通过配置中心或客户自管域名切换实例，客户端需要支持刷新接入地址，避免长期持有旧地址。使用客户自管域名时，还应验证 DNS TTL、客户端或 JVM DNS 缓存以及 TLS 主机名校验行为。
建议方案
方案 | 适用场景 | 容灾范围 | 核心前置要求 |
非核心链路，RTO 和 RPO 要求不高 | 实例内多节点和多可用区 | 客户端改造 | |
同地域实例级故障恢复，暂不做跨地域容灾 | 同地域实例级 | 消息同步、切换预案、幂等 | |
防范地域级故障或跨地域部署 | 跨地域 | 跨地域网络、消息同步、切换预案 | |
两地域或两实例同时承载流量 | 跨地域或跨实例 | 强幂等、去重、冲突处理、最终一致性 |
单实例基线方案
适用范围：非核心链路、可接受短时不可用、RTO 和 RPO 要求不高的业务。
建议：
若业务对稳定性、资源隔离或容量确定性有更高要求，建议优先选择铂金版或 Serverless 独享版，具体能力和 SLA 以实例类型说明及购买页为准。
客户端开启 Connection 自动重连，并具备 Channel 重建和消费者恢复能力。
按应用实例和业务并发建立多条长期 AMQP Connection，通过连接池分散生产和消费流量；不建议用单条 Connection 承载全部流量后只增加 Channel 数。
配置 Publisher Confirm、消费 ACK、超时重试、死信和告警。
按官方版本管理和升级通知要求完成实例版本升级，不长期运行已过期或停止维护的版本。
按监控指标对连接数、发送和消费流量、错误码、Queue 堆积、消费延迟和限流等关键指标配置告警。
风险：
单实例方案只能获得对应实例类型的产品 SLA，不等同于业务侧 100% 可用。
若业务不可接受单实例故障窗口，需要升级为多实例容灾方案。
同地域双实例主备方案
适用范围：希望提升同地域内实例级故障恢复能力，但暂不做跨地域容灾的核心业务。
关键设计：
在同一地域购买两个 RabbitMQ 实例。若业务对稳定性、资源隔离或容量确定性有更高要求，建议优先选择铂金版或 Serverless 独享版；同地域双实例仍不能替代跨地域容灾。
主备实例的 Vhost、Exchange、Queue、Binding、账号权限和网络访问策略应保持功能等价。建议通过自动化配置或应用启动声明管理资源，避免人工配置漂移；主备实例访问凭证应分别管理并按安全策略轮换。
消息同步可以选择以下方式：
应用双写：生产端同时写入主备实例。应用双写可降低单路写入失败造成的数据缺口，但不提供跨实例原子性保证，需要处理部分成功、确认超时、幂等重试和补偿。
全球消息路由：通过全球消息路由将主实例源 Queue 中的消息异步转发到备实例 Queue 或 Exchange。该方式存在同步延迟，RPO 取决于路由积压和网络状态；功能支持情况以实例类型说明和控制台为准。
全球消息路由会消费源 Queue 并将消息转发至目标端，不是对源 Queue 的旁路复制。不要直接复用业务消费者正在消费的 Queue 作为路由源。建议将源 Exchange 同时绑定业务 Queue 和容灾同步专用 Queue，再以容灾同步专用 Queue 作为路由源，具体语义可参考全球消息路由和 RabbitMQ Shovel。
若全球消息路由的目标类型选择 Exchange，应提前确认目标 Exchange 已绑定可存储消息的 Queue，避免消息路由到 Exchange 后无 Queue 承接而丢失。
消费者默认只消费主实例。切换时启动或放量备实例消费者，防止主备同时消费同一业务流造成重复副作用。
业务必须以业务消息 ID 做幂等，允许故障切换后出现重复投递或补偿投递。
切换流程建议：
监控确认主实例不可用或性能异常已影响业务发送或消费，且未在预期窗口内恢复。
按业务预案暂停、限流或降级生产侧写入，避免故障窗口内的主备数据差异继续扩大。
通过配置中心或应用接入地址配置切换到备实例；如使用客户自管 DNS，应确认 DNS 缓存和 TLS 校验不会阻碍切换。
启动备实例消费者或提升备实例消费权重。
观察发送成功率、消费速率、Queue 堆积和业务成功率。
主实例恢复后，基于业务发送与消费流水、堆积指标和业务消息 ID 完成对账、补偿和去重，再按变更流程回切。
跨地域主备容灾方案
适用范围：核心业务需要防范地域级故障，或业务本身跨地域部署。
关键设计：
在两个地域分别创建 RabbitMQ 实例，拓扑、账号权限和网络访问策略保持功能等价，访问凭证分别管理。
使用全球消息路由、应用双写或业务 Outbox 机制同步关键消息。全球消息路由的功能支持情况以实例类型说明和控制台为准。
使用全球消息路由时，应采用与同地域方案相同的容灾同步专用 Queue 设计，避免与业务消费者竞争消费源 Queue。
若全球消息路由的目标类型选择 Exchange，应提前确认目标 Exchange 已绑定可存储消息的 Queue。
使用全球消息路由时，需要评估 EventBridge 和 CEN 费用、消息同步延迟以及路由积压；使用应用双写或 Outbox 时，需要单独规划客户端网络、接入点、白名单、链路费用和故障切换方式。
目标端消息大小限制必须不低于源端，否则超过目标端限制的消息可能路由失败。
全球消息路由不支持传递路由，即 A 到 B 到 C 不会自动把 A 的消息经 B 继续传到 C；如需 A 到 C，应直接配置 A 到 C 的路由。
跨地域容灾不应默认假设完全透明切换。应明确 RTO、RPO、切换审批人、回切条件和数据补偿机制。
双活方案
适用范围：业务已经具备强幂等、去重、冲突处理和最终一致性能力，且希望两个地域或两个实例同时承载流量。双活属于客户应用架构设计，不代表产品自动提供跨实例双活或全局一致性能力。
要求：
生产端使用全局唯一且重试期间保持稳定的业务消息 ID。
消费端按业务主键做幂等和去重，不依赖 RabbitMQ 投递次数作为唯一事实。
明确每条消息的主写入路径和同步方向，避免双向同步形成循环或重复放大。
明确顺序语义边界。跨实例双活通常不提供全局严格顺序保障。
明确冲突处理策略，包括重复支付、重复下单、库存扣减等业务副作用。
具备持续演练和自动化对账能力。
不建议把双活作为默认方案。多数业务应优先选择主备或分级降级，避免因复杂度导致稳定性下降。
演练和验收标准
上线多实例容灾方案前，建议至少完成以下演练：
演练项 | 验证目标 |
主实例接入失败 | 客户端能按预期切到备实例，RTO 符合目标 |
主实例发送失败 | 生产端能识别失败并重试或补偿，不产生不可控重复 |
多连接分散 | 应用实例能按配置建立多条长期 Connection，重启或切换后连接池可恢复，生产和消费流量不会长期集中在单条 Connection 上 |
消费者重启 | 应用能重建 Channel 并重新建立消费者订阅 |
全球消息路由延迟 | 能观测源端专用 Queue 积压、目标端流入量和同步延迟 |
备实例接管消费 | 备实例消费者启动后能处理存量消息，业务幂等有效 |
回切主实例 | 能完成业务对账、补偿、去重和灰度回切 |
容灾方案的验收指标包括以下维度：
RTO：从业务受到影响或满足切换条件开始，到业务恢复的时间。
RPO：故障窗口内最多允许丢失或需要补偿的消息范围。
重复率：切换和回放期间重复消息比例及业务影响。
堆积恢复时间：切换后 Queue 堆积恢复到正常水位的时间。
客户端恢复成功率：Connection 重连、Channel 重建和消费者重新订阅的成功率。
连接分散度：应用重启、扩容或故障切换后，生产和消费流量应持续分散使用多条长期 Connection，避免长期只使用单条 Connection。