rabbitmq镜像队列集群必须先成功搭建普通集群，再通过rabbitmqctl set_policy显式配置镜像策略；否则队列仍单点存储、一挂全丢。关键前提包括：所有节点.erlang.cookie完全一致且权限为400、/etc/hosts双向解析正确、节点按stop_app→join_cluster→start_app顺序加入、防火墙放行4369/25672/5672端口。
直接说结论：RabbitMQ镜像队列集群不是“装完就能用”的功能，必须先搭好普通集群，再通过 rabbitmqctl set_policy 显式启用镜像策略；否则你看到的只是多个节点各自为政，队列仍单点存储、一挂全丢。
普通集群没跑通，镜像队列根本不会生效
很多人卡在第一步：三个节点都启动了，rabbitmqctl cluster_status 显示成员正常，但创建的队列始终只在一个节点上。这说明集群只是“元数据连上了”，实际消息路由和队列分布没打通。
- 所有节点的
/var/lib/rabbitmq/.erlang.cookie必须完全一致（包括权限：400，属主rabbitmq:rabbitmq） -
/etc/hosts里必须有双向可解析的 hostname 映射，比如rabbit@node1能 ping 通node1，且hostname -f输出与RABBITMQ_NODENAME匹配 - 节点加入顺序要严格：先停掉所有节点的 app（
rabbitmqctl stop_app），再在主节点执行join_cluster，最后统一start_app - 防火墙必须放行
4369（epmd）、25672（Erlang 分布式端口）、5672（AMQP）——缺一个，cluster_status就可能显示 “disc” 但实际不通信
rabbitmqctl set_policy 的参数陷阱
镜像策略不是“开了就高可用”，ha-mode 和 ha-params 搭配错，会导致队列无法创建、同步卡死或主从切换失败。
-
ha-mode: all看起来最安全，但要求集群所有节点都在线才能创建队列；只要一个节点失联，新队列直接创建失败，报错{error,not_all_nodes_online} -
ha-mode: exactly更实用，比如三节点集群设ha-params: 2，表示“一主一从”，主节点挂后自动升从节点为主，剩余节点继续服务；但注意：如果只剩一个节点存活，它会拒绝成为主节点（防止脑裂），队列进入down状态 -
ha-sync-mode: automatic对小队列友好，但大消息积压时会阻塞生产者；若队列已有百万级消息，建议改manual，后续用rabbitmqctl sync_queue手动触发 - 策略正则匹配要小心：
"^"匹配所有队列，但如果你有多个 vhost，得加-p my_vhost参数，否则只作用于默认/
镜像队列状态怎么看？别只信 Web UI
管理界面里“Mirrored”标签页只显示镜像数量，不反映同步是否完成。真正判断是否可靠，得看命令行输出：
-
rabbitmqctl list_queues name messages_slave_pids synchronised_slave_pids—— 如果synchronised_slave_pids是空列表，说明从节点还没同步完，此时主节点宕机就会丢消息 -
rabbitmqctl list_policies必须确认策略apply-to是queues，不是exchanges或all；后者对镜像队列无效 - 查具体队列细节：
rabbitmqctl list_queues name slave_pids state，state字段为running才代表主从都在工作；若为down或idle，说明镜像未激活
最容易被忽略的一点：镜像队列不等于数据零丢失。如果主节点在消息写入磁盘前崩溃，而从节点尚未收到该消息（即非 ha-sync-mode: automatic 且未开启 publish_confirms），这部分消息依然会丢失。所以生产环境务必开启 publisher confirms + durable 队列 + mandatory 标志，把可靠性责任落到客户端侧。
