镜像队列策略必须通过 rabbitmqctl set_policy 或 http api 配置，web ui 不支持；ha-mode 有 all、exactly、nodes 三种模式，行为差异显著；策略需匹配队列名正则且 apply-to 正确，新建队列才生效；镜像不能实现毫秒级无感切换，主节点崩溃仍有数秒不可用，业务须容错实测。
镜像队列策略必须用 rabbitmqctl set_policy 设置，Web UI 不支持
Policy 是 RabbitMQ 实现镜像队列的唯一配置入口，Web 管理界面里根本找不到“镜像”开关。你看到的队列详情页里 ha-mode 字段为空，不是没生效，是压根没配策略。
常见错误：在 Web UI 创建队列后手动点“Make queue HA”，结果毫无反应——因为这个按钮早已被移除（从 3.8.0 起）。所有策略都得走命令行或 HTTP API。
- 必须用
rabbitmqctl set_policy，例如：rabbitmqctl set_policy ha-two "^" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}' -
^是正则匹配所有队列，生产环境务必换成具体前缀，比如^ha\. -
ha-sync-mode推荐设为automatic；manual模式下新增节点不会自动同步，容易漏数据
ha-mode 的三种取值区别直接影响故障恢复行为
不是设了 ha-mode 就万事大吉。不同模式下主节点挂掉时，从节点能否接管、是否丢消息、要不要人工干预，全看这里。
-
all：所有在线节点都存副本。节点数下降时，队列会降级但不中断；缺点是写入性能随节点数线性下降 -
exactly：严格维持指定数量副本（如"ha-params":2）。节点扩缩容时需手动调策略，否则可能只剩 1 副本裸奔 -
nodes：指定具体节点名列表，比如["rabbit@node1","rabbit@node2"]。适合跨机房部署，但节点名写错一个就策略不生效
注意：ha-params 在 all 模式下无效，在 nodes 模式下是数组，在 exactly 下才是数字。
新队列不自动镜像？检查策略的 apply-to 和匹配范围
策略生效的前提是：队列名匹配策略的 pattern，且策略的 apply-to 包含 queues（默认值）或 all。常见坑是只写了 pattern，却忘了队列是动态创建的。
- 如果用
apply-to queues（默认），已有队列不会被 retroactively 镜像，只对后续新建队列生效 - pattern 必须是正则表达式，
test不等于^test$，后者才精确匹配队列名test；想匹配所有以ha.开头的队列，得写^ha\. - 策略名不能重复，同名策略会被覆盖。用
rabbitmqctl list_policies确认是否已存在冲突策略
执行完 set_policy 后，立刻用 rabbitmqctl list_queues name policy 查看目标队列的 policy 列是否显示策略名，这是最直接的验证方式。
镜像队列不是万能高可用，主节点崩溃时仍有几秒不可用
镜像解决的是单点存储故障，不是毫秒级无感切换。RabbitMQ 主从切换需要选举新主、重建连接、重发未确认消息，这段时间客户端会收到 channel error: NOT_FOUND 或连接中断。
- 消费者必须实现重连 + 重新声明队列 + 拉取消息逻辑，不能依赖“一直连着就没事”
- 发布端若用 publisher confirms，主挂掉瞬间未 confirm 的消息会丢失，除非配合
mandatory+return回调重发 - 集群脑裂（split-brain）时，两个分区各自选出主，旧主恢复后变成“孤立节点”，其上的镜像队列会被强制清空——所以必须配
cluster_partition_handling，推荐pause_minority
真正关键的不是“能不能镜像”，而是你的业务能否容忍这几秒断连和最多一条消息的不确定性。这点经常被文档一笔带过，但上线前必须实测验证。
