在 RabbitMQ 集群中，配置镜像队列是通过设置策略（Policy）将队列同步复制到多个节点，从而实现单节点故障时服务不中断；但需注意，自 RabbitMQ 3.8.0 起官方更推荐使用仲裁队列（Quorum Queues），镜像队列主要适用于存量系统维护。
先说结论：镜像队列能解决单点故障，但会带来性能开销，新业务建议优先考虑仲裁队列，旧系统可通过策略一键开启镜像。
- 适合：需要队列级高可用、无法立即迁移至仲裁队列的存量集群环境。
- 先准备：确保至少 3 个节点组成集群，且节点间网络稳定、Erlang Cookie 一致。
- 验收：通过命令行或管理界面确认策略生效，并模拟节点故障验证消息不丢失。
- 风险提示：RabbitMQ 3.8+ 版本中镜像队列已处于维护模式，新建业务请优先评估仲裁队列。
命令速用版
如果已准备好集群，可直接使用以下命令为所有队列开启镜像策略（复制到所有节点）：
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all","ha-sync-mode":"automatic"}' `--priority` 1参数说明：
ha-all：策略名称，可自定义。^：正则表达式，匹配所有队列。ha-mode: all：镜像到集群所有节点。ha-sync-mode: automatic：新节点自动同步数据（需 RabbitMQ 3.8+ 支持，旧版本可能忽略此参数）。`--priority` 1：策略优先级，数值越高优先级越高。
集群环境初始化
在执行镜像配置前，必须确保节点已正确加入集群。以下是基于 Linux 环境的标准搭建步骤：
1. 同步 Erlang Cookie
RabbitMQ 节点间通信依赖相同的 Cookie。将主节点的 Cookie 复制到从节点：
# 在主节点查看或生成 cookie
cat /var/lib/rabbitmq/.erlang.cookie# 在从节点覆盖 cookie (路径可能因安装方式不同而异)
cp /var/lib/rabbitmq/.erlang.cookie /path/to/node2/
chmod 400 /path/to/node2/.erlang.cookie
chown rabbitmq:rabbitmq /path/to/node2/.erlang.cookie2. 加入集群
在从节点执行以下命令加入主节点集群（假设主节点主机名为 rabbit@node1）：
# 停止应用
rabbitmqctl stop_app# 加入集群
rabbitmqctl join_cluster rabbit@node1# 启动应用
rabbitmqctl start_app3. 确认状态
在主节点执行 rabbitmqctl cluster_status，检查 running_nodes 是否包含所有预期节点。
镜像队列与仲裁队列对比
在决定使用镜像队列前，建议对比官方推荐的仲裁队列特性：
| 特性 | 镜像队列 (Mirrored) | 仲裁队列 (Quorum) |
|---|---|---|
| 一致性模型 | 最终一致性 | 强一致性 (Raft) |
| 故障恢复 | 可能丢失少量消息 | 数据不丢失 |
| 性能开销 | 较低 (异步复制) | 较高 (共识算法) |
| 官方状态 | 维护模式 (3.8+) | 推荐方案 |
| 适用场景 | 存量系统维护 | 新业务核心数据 |
为什么会这样
普通 RabbitMQ 队列默认只存在于单个节点，一旦该节点宕机，队列及其未消费消息将不可用。镜像队列通过主从模型（Master/Slave）解决这一问题：主节点处理读写，从节点实时同步数据。当主节点故障时，集群会自动选举新的主节点，对客户端透明。
但镜像并非免费午餐，数据同步会增加网络带宽和磁盘 I/O 开销。因此，官方在新版本中引入了基于 Raft 共识算法的仲裁队列，提供更强的一致性。如果是在 3.8.0 以上版本新建业务，建议评估是否直接使用仲裁队列。
分步处理
步骤 1：确认集群状态
在执行镜像配置前，必须确保节点已加入集群。在主节点执行：
rabbitmqctl cluster_status检查输出中running_nodes是否包含所有预期节点。若未组建集群，需统一各节点的.erlang.cookie文件，并使用rabbitmqctl join_cluster命令加入。
步骤 2：定义镜像策略
根据业务需求选择复制模式。若追求最高可用且节点少，用all；若节点多且想节省资源，可用exactly指定副本数（如 3 节点集群设 2 副本）：
rabbitmqctl set_policy ha-exactly "^" '{"ha-mode":"exactly","ha-params":"2","ha-sync-mode":"automatic"}'步骤 3：应用策略
策略设置后立即生效，新创建的队列会自动继承。已有队列可能需要手动同步或重启应用才能触发镜像。
怎么验证是否生效
1. 查看策略列表
使用命令确认策略已存在：
rabbitmqctl list_policies2. 检查队列状态
在管理界面或通过命令查看队列详情，确认mirrors字段不为空，且显示有多个节点副本。
rabbitmqctl list_queues name mirrors3. 故障演练
在测试环境停止一个节点服务，观察消费者是否中断，消息是否丢失。正常情况应有短暂连接波动但消息不丢。
常见坑
- 网络开销过大：若集群节点多且使用
ha-mode: all，消息同步流量会成倍增长，可能拖慢集群。建议节点多时使用exactly模式。 - 脑裂风险：集群建议采用奇数节点（如 3 节点），避免网络分区时无法选举主节点。
- 版本差异：RabbitMQ 3.8.0 之后官方推荐仲裁队列，镜像队列处于维护模式。新业务若无历史包袱，优先调研仲裁队列。
- 同步性能：大型队列开启镜像时，初始同步可能耗时较长，建议避开业务高峰期操作。
- 参数兼容性：
ha-sync-mode在部分旧版本中不支持，若命令报错可移除该参数尝试。
参考来源
- RabbitMQ High Availability (Official Docs)
- RabbitMQ Quorum Queues (Official Docs)
- RabbitMQ Clustering (Official Docs)
原文链接：https://www.zjcp.cc/ask/11564.html