RabbitMQ 系列收尾篇。单点 RabbitMQ 在生产就是定时炸弹——机器一挂，业务全瘫。本篇把 RabbitMQ 的四种集群/高可用模式讲透：普通集群、镜像队列、Warren（主备）、Shovel（远程）。生产选哪种、各自的开销与坑，全部摊开讲。
一、四种模式总览
| 模式 | 别名 | 数据分布 | 高可用 | 典型场景 |
|---|---|---|---|---|
| 普通集群 | — | 元数据共享、消息单点 | ❌ | 扩展吞吐，不保证 HA |
| 镜像队列 | Mirror Queue | 每个节点都有完整副本 | ✅ | 生产标配（HA） |
| Warren | 主备模式 | 主提供读写、备不读写 | ✅（故障切换） | 小规模、低成本 HA |
| Shovel | 远程模式 | 跨数据中心复制 | ✅（异地容灾） | 异地双活、灾备 |
生产环境几乎只选镜像队列（或现代的 Quorum Queue）。普通集群是为了扩展、不是为了 HA；Warren 和 Shovel 是特殊场景的补充。
二、普通集群模式
多台机器组成集群，每台机器只记录交换机和绑定信息（元数据），而不记录队列的实际消息数据。
2.1 工作机制
- 生产者、消费者连到节点 1 时，如果消费的队列就在节点 1 上 → 直接消费
- 当消费者连到节点 2 或节点 3 时，这两个节点起路由转发作用——把请求转发到节点 1，或从节点 1 拉取数据再消费
2.2 单点故障
- 节点 1 挂掉后，队列 1 不再可以提供服务
- 但位于节点 2 的队列 2 依旧可以提供服务
2.3 为什么不让每个节点都存队列数据？
这是 RabbitMQ 设计上很有意思的取舍：
假设一台 1G 内存的机器，队列数据已经撑满。如果每台都存全部队列，再扩容一台 1G 的机器，它还是满的——根本起不到扩容的目的。
所以普通集群选择「消息单点存、元数据全集群共享」，是为了真正能水平扩展存储。代价就是单点故障会丢消息。
2.4 适用场景
- 业务对消息可靠性不敏感（如日志类）
- 想要提升集群整体吞吐（不同队列分布在不同节点）
- ❌ 不适合需要 HA 的核心业务
三、镜像集群模式
每台机器都有全部队列的镜像，能真正实现高可用。
3.1 数据同步机制
发送到镜像队列的消息会同时发送到 master 和所有 slave（就像 fanout 交换机一样）：
- master 挂了，消息依然到达 slave，防丢
- 资历最老的 slave（加入时间最久的）会被提升为新的 master
3.2 为什么所有操作都走 master
除了消息接收（master 和 slave 同时收）外，其他所有动作都只向 master 发送，再由 master 按顺序把结果广播给各 slave：
- 消费者与 slave 建立连接消费时，slave 先把请求转发给 master
- master 把数据发给 slave，再由 slave 发给消费者
为什么这么设计？ 这与 MySQL 的主从不一样：MySQL 从库是只读的，而 MQ 的 slave 涉及「消费即删除」操作。如果允许直接操作 slave，会出现消息乱序、重复消费。所有操作都从 master 走，能保证：
- 消息的有序性
- 消费的不重复
3.3 master 是「队列级」而非「节点级」
不必担心 master 节点压力过大——master 是针对队列而言，不是针对服务器。
一台服务器上的 RabbitMQ 实例里，某些队列是主节点，其他队列是从节点——这样负载自然分散到所有节点上，达到负载均衡。
3.4 缺点
- 队列每次数据变更都要同步到全部节点，性能损耗严重
- 占用机器资源多（每个节点都存全量）
- 节点数越多，同步开销越大（一般 3~5 节点封顶）
3.5 通过 Policy 开启镜像
# 给以 ha. 开头的队列设置镜像策略：所有节点都镜像、自动同步
rabbitmqctl set_policy ha-all "^ha\." \
'{"ha-mode":"all","ha-sync-mode":"automatic"}'ha-mode | 含义 |
|---|---|
all | 队列在所有节点上镜像（节点多时开销大） |
exactly | 镜像到指定数量的节点（如 exactly + ha-params: 2 = 主+1 从） |
nodes | 镜像到指定节点名列表 |
生产推荐
exactly+ 2 副本（主+1 从）——既保证 HA，又控制开销。all模式下节点超过 5 个会明显感觉到同步延迟。
四、Warren 模式（主备模式）
主备模式，也叫 Warren 模式（兔子窝模式）：
- 主节点提供读写，备用节点不提供读写
- 主节点故障或宕机时，切换：备用节点升级为主节点继续服务
一般实现为一主一备或一主多备。
4.1 适用场景
- 并发数和数据量不高的小型项目
- 想要简单可用的 HA，不想配复杂集群
- 成本敏感（备机闲置也是钱）
Warren 和镜像队列的本质区别：Warren 的备机不工作，只在主机挂时接管；镜像队列的 slave 始终在工作（接受消息同步）。所以 Warren 资源利用率低，但运维简单。
五、Shovel 模式（远程模式）
Shovel 是双活的一种模式——把消息跨数据中心复制，可以跨地域让两个 MQ 互联。
5.1 工作机制
它是 RabbitMQ 早期的集群架构模型。典型实现：
- 把队列分为工作队列（work）和备份队列（backup）
- 当监听到工作队列负载过高时，自动投递到 backup 队列
- backup 队列与另一集群建立的 Shovel 联系，把数据复制到远端 MQ
- 在远端进行消费
5.2 图解
图中的「Shovel 订单处理拓扑」展示了完整流程：
源端（Goleta 仓库集群） 目标端（Carpinteria 仓库集群）
┌─────────────────────────────────┐ ┌────────────────────────────┐
│ incoming orders exchange │ │ incoming orders exchange │
│ │ │ │ │ │
│ ├──► warehouse_goleta queue │ │ └──► warehouse_ │
│ │ │ Shovel │ carpinteria queue│
│ └──► backup_orders queue ───┼──────────►│ (远端消费) │
│ │ 持续拉取 │ │
└─────────────────────────────────┘ └────────────────────────────┘5.3 适用场景
- 跨地域容灾（两地三中心）
- 异地双活
- 把边缘节点的消息汇聚到中心集群
Shovel 与 Federation（联邦）的区别：Shovel 是单方向搬运（source → destination），Federation 是Exchange/Queue 级别的双向联邦。前者轻量、后者灵活。
六、四种模式怎么选
| 你的需求 | 推荐模式 |
|---|---|
| 单机就够、只想练手 | — |
| 想扩展吞吐、不在意 HA | 普通集群 |
| 生产核心业务、要 HA | 镜像队列（或 Quorum Queue） |
| 小规模、低成本的 HA | Warren |
| 跨地域容灾 | Shovel + 镜像 |
| 大规模生产、强一致性 | Quorum Queue（Raft） |
绝大多数团队：从镜像队列起步（3 节点 +
exactly+ 2 副本），需要异地容灾再加 Shovel。Warren 几乎没人用——它的「备机闲置」实在太浪费。
七、镜像队列 vs Quorum Queue（番外）
这是 2018 年笔记里没有的内容，补在 2026 视角下。
RabbitMQ 官方从 3.8 开始推荐用 Quorum Queue（基于 Raft 的仲裁队列）替代老的镜像队列：
| 维度 | 镜像队列（Mirror） | Quorum Queue |
|---|---|---|
| 一致性算法 | 自研（master-slave 广播） | Raft |
| 数据存储 | Mnesia | 基于日志（WAL） |
| 故障切换 | 老 slave 提升 | Raft 选举 |
| 性能 | 较好 | 略低（强一致代价） |
| 未来 | 官方计划废弃 | 主推 |
| 启用方式 | Policy ha-mode | 声明队列时 x-queue-type: quorum |
新项目直接上 Quorum Queue。镜像队列官方明确说要废弃——2026 年起，新建的 RabbitMQ 集群不建议再用
ha-mode了。
八、小结
RabbitMQ 的集群选型本质上是一道「一致性 vs 性能 vs 复杂度」的三方权衡题：
- 普通集群：性能最好、HA 最差
- 镜像队列：HA 最好、性能开销大
- Warren：HA 简单、资源浪费
- Shovel：跨地域、单向复制
- Quorum Queue（新）：强一致、官方主推
不管选哪种，单点 RabbitMQ 在生产环境是不可接受的——这是 RabbitMQ 系列最该记住的一句话。
至此「一文拿下 MQ」的 RabbitMQ 部分结束。下一篇切换到 Kafka 系列——讲清它为什么吞吐量这么大、日志结构怎么设计、零拷贝是怎么省时间的。
下一篇「Kafka（上）：特性、应用场景与消息传递保障」。
现代视角补一句（2026）：到 2026 年，Kafka 已经从「日志专用」全面进入「业务消息」领域——KRaft 去掉 ZK 依赖、Transactions 完善事务消息、Partition Tiered Storage 解决堆积问题。RabbitMQ 和 Kafka 的边界正在模糊。但 RabbitMQ 的复杂路由能力、低延迟 μs 级优势依然独有——选型逻辑还是看场景。