镜像集群能防止单点故障，普通集群不能；镜像集群需显式配置策略同步消息，代价是带宽与磁盘开销增加，且自rabbitmq 3.8.0起已被标记为deprecated，推荐使用quorum queue替代。
普通集群不能防止单点故障，镜像集群能，但代价是带宽和磁盘占用翻倍——选哪个，取决于你能不能接受消息丢失、愿不愿意为高可用多付两台机器的钱。
普通集群只同步元数据，不复制消息
队列的名称、绑定关系、vHost 权限这些会在所有节点间自动同步，但 queue 里实际的消息只存放在创建它的那个节点上。其他节点查到这个队列不在本地，就会转发请求过去，相当于“远程调用”。
- 客户端连任意节点发消息，最终都落到主节点存储
- 主节点宕机后，该队列立刻不可用；即使开了持久化，也要等它恢复才能继续消费
- 没有自动故障转移，也没有副本，
rabbitmqctl cluster_status显示节点都在线，但某个队列可能已“失联” - 适合日志上报、埋点统计这类允许少量丢失、读多写少的场景
镜像集群靠策略触发消息同步，不是默认行为
普通集群搭好后，镜像功能是关着的。必须显式配置 ha-mode 和 ha-sync-mode 等策略，RabbitMQ 才会把匹配的队列复制到多个节点。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 策略生效范围由正则匹配队列名决定，比如
^order\.只镜像订单相关队列 -
ha-mode: exactly指定副本数（如 3），ha-mode: all表示所有节点都存一份，但节点增减时需手动重同步 - 同步是异步的，
ha-sync-mode: automatic会让新镜像节点自动追平，manual则要人工触发rabbitmqctl sync_queue - 主节点挂了，镜像节点秒级选举新主，消费者无感知——但注意：未确认消息（unack）可能重复投递
3.12+ 版本起，镜像集群已被标记为 deprecated
官方文档明确写着“mirrored queues is deprecated since 3.8.0, replaced by quorum queues”。这不是建议，是事实：Erlang 层面的同步机制存在脑裂风险，Raft 协议的 quorum queue 才是当前生产首选。
- 如果你用的是 RabbitMQ 3.12 或更新版本，
mirrored_queue策略仍能工作，但管理界面里已不显示“镜像”选项，命令行也只保留兼容性支持 - 新建集群应直接用
quorum queue：创建时指定x-queue-type: quorum，无需额外策略，自带强一致和自动故障恢复 - 老项目升级时，别强行把
mirrored改成quorum，因为二者不兼容——得停业务、导出消息、重建队列
真正容易被忽略的点是：镜像策略只对新声明的队列生效。已经存在的队列不会自动被镜像，哪怕你后来加了策略。上线前务必用 rabbitmqadmin list queues name policy 检查每条队列是否命中策略，而不是只看策略本身是否存在。
