消息队列 RabbitMQ 版提供多维度高可用能力，例如跨可用区部署、数据持久化，有效提升消息服务的稳定性和容灾能力
集群高可用
集群类型 | 高可用能力 | 说明 |
开源托管版 | 跨可用区部署 | 在拥有两个或以上可用区的地域购买 RabbitMQ 开源托管版集群时，可以选择 2-3 个可用区进行部署。节点会均匀打散分布在各可用区上。这种部署方式能够让集群在单个可用区不可用的情况下，仍能正常提供服务。 |
Serverless 版 | | 集群底层默认跨多可用区部署，无需手动选择可用区，集群节点会自动分布在多个可用区，即使单个可用区故障也不影响服务，实现机房级容灾。 |
数据高可用
集群类型 | 高可用能力 | 说明 |
开源托管版 | 镜像队列 | 多节点支持开启镜像队列，可配置多副本同步。 镜像队列可以在 RabbitMQ 集群中的多个节点上复制队列中的消息，确保在某个节点发生故障时，队列中的消息不会丢失，保证服务的可用性。 |
Serverless 版 | 数据持久化三副本 | 集群默认支持数据持久化三副本，通过数据持久化存储和多节点冗余备份的双重保障，确保业务数据在任何情况下都不会丢失，服务不会中断。 |
跨多可用区部署
概述
消息队列 RabbitMQ 版（TDMQ for RabbitMQ）支持在多个可用区（Availability Zone，简称 AZ）部署集群节点，并基于开源 RabbitMQ 的 镜像队列（Classic Mirrored Queues） 机制提供跨 AZ 的数据冗余与故障切换能力。
TDMQ for RabbitMQ 的集群节点数固定为 奇数，可选 1 / 3 / 5 / 7 节点，其中 3 节点 是最常见的部署形态。本文统一以 3 节点集群为例，介绍其在 2AZ 与 3AZ 部署下的高可用能力差异、网络分区故障下的行为表现，以及购买实例时的多 AZ 选型建议。
注意：
只有 RabbitMQ 托管版才有镜像队列，因此会存在网络分区的风险。RabbitMQ Serverless 不依赖镜像队列，基于底层存算分离架构实现集群的高可用能力，不存在网络分区的问题。
镜像队列说明
镜像队列是开源 RabbitMQ 提供的经典高可用方案，其核心思想是：将一个队列的数据，从 主节点（Master / Leader） 同步复制到一个或多个 镜像节点（Mirror / Follower）。当主节点所在 Broker 不可用时，集群将从健康的镜像中选举一个新的主节点，对客户端继续提供服务。
镜像队列通过 Policy 进行配置，关键参数如下：
参数 | 说明 | TDMQ for RabbitMQ 默认参数值 |
ha-mode | 镜像策略模式：all（全节点镜像）/ exactly（指定副本数）/ nodes（指定节点） | exactly |
ha-params | 当 ha-mode=exactly 时，指定副本总数（含主节点） | 3 |
ha-sync-mode | 新副本同步方式：automatic（自动同步）/ manual（手动） | manual |
ha-promote-on-shutdown | 主节点优雅停机时是否允许提升未同步的镜像 | when-synced |
ha-promote-on-failure | 主节点崩溃时是否允许提升未同步的镜像 | always（高可用） |
说明：
镜像队列默认副本数为 3（即每个节点都持有一份完整数据），保证任意节点存活都能恢复消息。需要注意的是，镜像队列模式下集群 TDMQ for RabbitMQ 默认使用 autoheal 分区处理策略，少数派子集并不会自动暂停。
单 AZ 部署场景下的高可用能力（3 节点）
3 节点集群部署在同一个可用区内，所有节点共享同一物理基础设施（机房、电力、网络出口）。
可承受任意单节点宕机：剩余 2 节点构成多数派，集群继续读写，业务侧仅感知亚秒级抖动；
无法应对 AZ 级故障：单 AZ 整机房断电、断网、消防、空调故障等场景下，集群整体不可用，且未同步消息可能永久丢失；
无任何跨 AZ 容灾能力：与 RabbitMQ 单机部署的容灾边界相同，仅多了节点级故障容忍。
2AZ 部署场景下的高可用能力（3 节点）
部署形态
3 节点集群在 2AZ 形态下，因节点数为奇数，必然形成 2 + 1 的不对称结构：主 AZ 部署 2 个节点、备 AZ 部署 1 个节点。
镜像队列默认按 ha-mode=exactly, ha-params=3 配置（即三个节点都持有完整副本），并通过 Queue Master Locator 策略让主副本均衡分布。
可承受的故障范围
2AZ / 3 节点部署在以下故障场景下可保持服务可用：
任意单节点宕机：剩余节点仍持有完整镜像副本，集群可继续读写；
AZ-B（备 AZ，1 节点）整体故障：剩余 2 个节点仍在 AZ-A，构成多数派，常仅出现短暂抖动/重连，具体取决于客户端重连与连接池参数；
AZ-A（主 AZ，2 节点）整体故障：AZ-B 的 1 个节点持有完整镜像副本，当分区处理策略为 autoheal （TDMQ for RabbitMQ 默认策略）时，集群以单节点方式继续提供读写服务，业务可用性保持；
跨 AZ 网络抖动：抖动恢复后，如果 ha-sync-mode=manual（TDMQ for RabbitMQ 默认策略） 需要手工同步，如果 ha-sync-mode=automatic，则自动同步。
3AZ 相比 2AZ 额外提升的高可用能力（3 节点）
部署形态
3 节点集群在 3AZ 形态下，每个 AZ 各部署 1 个节点（1+1+1），形成完全对称的拓扑。
三种部署形态容灾能力对比
能力维度 | 单 AZ | 2AZ（2+1） | 3AZ（1+1+1） |
单节点故障 | 自动切换 | 自动切换 | 自动切换 |
网络复杂度 | 不涉及跨 AZ 问题 | 网络复杂度低 | 网络复杂度高，更容易出现网络分区问题 |
单 AZ 整体故障 | 集群完全不可用 | 备 AZ 故障无感；主 AZ 故障会降级为单节点运行，存在少量未同步消息丢失 | 任意 AZ 故障均自动切换，剩余 2AZ 仍持有完整副本 |
网络分区脑裂风险 | 基本不会发生 | 默认 autoheal 策略下，少数派 AZ 在分区期间继续接收消息，恢复时被强制丢弃 | 多数派始终在另两个 AZ，少数派 AZ 影响面仅 1/3 |
AZ 故障期间高可用能力 | 无 AZ 冗余 | 主 AZ 故障后退化为单点，无 HA | 任一 AZ 故障后仍剩 2 节点互为镜像 |
镜像副本分布 | 单 AZ | 副本最多分布在 2AZ | 副本天然分布在 3AZ，跨 AZ 容灾粒度更细 |
网络分区故障下的行为对比（3 节点）
网络分区是使用 RabbitMQ 时需要面对的一类典型故障：单机网络异常或内部通信端口不通，节点间无法通信即可能触发分区。TDMQ for RabbitMQ 默认 net_ticktime=60s，分区判定窗口为 45s ~ 75s（可配置，非固定值），分区发生时各子集会认为对方节点已 down，元数据操作仅在本子集生效。
分区会带来什么风险
未配置镜像队列时：发送方仍可投递但可能路由失败，需配合 mandatory + Basic.Return 处理；消费方可能出现 ack 失效；分区恢复后元数据不丢，但可能消息重复。
配置了镜像队列时（TDMQ for RabbitMQ 默认形态）：每个子集都会独立选出 master，互相独立运行；分区恢复时还要看 ha-sync-mode：
manual（默认）：当新的 slave 节点加入时，不会同步 master 节点上的旧数据。但如果此时 master 节点发生异常，那么此部分数据可能会丢失。
automatic：当新的 slave 节点加入时，会自动同步 master 节点中的数据。队列数据同步过程中，队列服务不可用，客户端连接会被阻塞。如果 master 节点中有大量的消息堆积，比如会造成 slave 节点的同步时间增长，进一步影响集群服务的可用性。
镜像队列默认采用 autoheal 策略：分区期间各子集双写，恢复时按"客户端连接数最多 → 节点数最多"规则选出获胜方，输家节点重启，输家分区期间产生的消息被丢弃。
腾讯云 TDMQ for RabbitMQ 的监控与恢复
分钟级拨测：覆盖网络分区、端口 down 等指标，均配置电话告警，运维侧分钟级介入；
默认 autoheal：集群自动选出获胜分区并重启输家节点，加速分区收敛，无需人工干预；
VIP 接入：分区期间客户端流量自动引流至获胜分区，避免持续连到将被重启的节点。
客户端侧建议
1. 发送方：开 publisher confirm + mandatory，处理 Basic.Return，识别分区期间的路由失败；
2. 消费方：分区恢复时可能消息重复，消费侧必须做幂等；
3. 配置堆积告警：分区恢复后 slave 重新追平的时长正比于 master 堆积量，建议配置监控。
多 AZ 选购建议
双 AZ 和 三 AZ 都能满足单 AZ 故障场景下的容灾要求，达到 SLA 99.95%，建议根据业务的实际场景进行选择。
