RabbitMQ镜像队列是服务端集群机制，Java应用需配合配置：手动ACK、持久化队列与消息、多地址连接及自动恢复；策略由服务端配置，新项目应优先使用仲裁队列。
镜像队列的本质是服务端自动复制
镜像队列由 RabbitMQ 服务端策略（Policy）驱动：队列数据（消息体、未确认状态、元数据）在集群多个节点间实时同步，形成一主多从结构。主节点（Master）处理全部读写请求，镜像节点（Mirror）只同步日志、不直连客户端。主节点宕机后，RabbitMQ 自动选举最老的镜像节点升为新主——整个过程对 Java 客户端完全透明。
Java 端必须做好的三件事
虽然镜像逻辑在服务端，但 Java 应用若忽略以下三点，高可用就会失效：
-
禁用 autoAck，启用手动 ACK：设置
channel.basicConsume(queue, false, ...)，业务处理完成后显式调用basicAck()。否则主节点崩溃时未确认消息可能被新主重复投递。 -
声明持久化队列与消息：队列声明必须含
durable=true；交换器需 durable；发送消息时MessageProperties.PERSISTENT_TEXT_PLAIN不可少。非持久化队列无法参与镜像，且重启即丢失。 -
连接支持多地址与自动恢复：Spring AMQP 中配置
CachingConnectionFactory的addresses为多个节点（如rabbitmq01:5672,rabbitmq02:5672,rabbitmq03:5672），并开启automaticRecoveryEnabled=true和topologyRecoveryEnabled=true。
服务端策略配置决定镜像效果
Java 应用无需写策略代码，但需确认集群已按需配置 Policy（例如通过 rabbitmqctl set_policy）：
-
匹配范围合理：策略名对应队列命名规则，如
^order\.只镜像订单类队列，避免全量镜像拖慢性能。 -
镜像数量适中：不推荐
ha-mode=all（尤其节点数 >3），建议用exactly模式指定镜像数（如 3 节点集群设为 2 或 3），兼顾可靠性与吞吐。 - 同步模式设为 automatic：确保新镜像节点加入时自动同步历史消息，避免手动同步导致数据滞后或丢失。
注意：镜像队列已是传统方案
RabbitMQ 官方自 3.8 版起主推仲裁队列（Quorum Queue），基于 Raft 协议实现强一致、无脑裂、自动选主。新项目应优先选用 .quorum() 声明队列；镜像队列仅适用于存量系统迁移过渡，不再推荐用于新架构设计。
立即学习“Java免费学习笔记（深入）”；
