RabbitMQ 无应用层自动故障转移，需客户端配合实现；Java 客户端应配置多地址、启用 automaticRecovery 和 topologyRecovery，并推荐结合 DNS SRV 或服务发现，同时确保服务端集群、镜像队列及网络等基础高可用。
RabbitMQ 本身不提供应用层的“自动故障转移”能力，所谓故障转移需由客户端（如 Java 应用）主动配合集群拓扑与连接策略来实现。关键在于：让 Java 客户端感知节点状态、自动重连可用节点，并避免单点依赖。
使用支持集群发现的 ConnectionFactory 配置
RabbitMQ Java Client 自 5.0+ 版本起原生支持自动节点发现（通过 Automatic Recovery 和 Topology Recovery），但需正确启用并配置多个地址：
- 在
ConnectionFactory中调用setAddresses("node1:5672,node2:5672,node3:5672")，而非只设一个 host/port - 启用自动恢复：
factory.setAutomaticRecoveryEnabled(true) - 开启拓扑恢复（重建 Exchange/Queue/Binding）：
factory.setTopologyRecoveryEnabled(true) - 可选：设置重试间隔和最大尝试次数，例如
factory.setNetworkRecoveryInterval(10_000)
利用 DNS SRV 记录或服务发现机制（生产推荐）
硬编码节点列表在动态环境中易过时。更健壮的方式是交由基础设施层解耦：
- 部署 RabbitMQ 集群时，配合 Consul / Kubernetes Service / DNS SRV 提供统一入口
- Java 应用通过域名（如
mq-cluster.example.com）连接，由 DNS 或服务网格解析到健康节点 - 客户端仍需开启
automaticRecovery，但地址只需填该域名 + 端口，无需感知具体 IP - K8s 场景下，Headless Service + StatefulSet 可结合 readiness probe 实现节点级健康剔除
监听连接事件并主动干预（高级控制）
默认自动恢复适用于大多数场景，但若需定制逻辑（如降级日志、熔断、切换备用集群），可注册监听器：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
立即学习“Java免费学习笔记（深入）”；
- 实现
ExceptionHandler，捕获IOException或ShutdownSignalException - 重写
handleConnectionFailure方法，在连接断开时触发自定义动作（如上报 Prometheus、切换备用连接池） - 注意：不要在回调中阻塞主线程；建议异步处理，避免影响恢复流程
集群高可用前提：RabbitMQ 侧必须正确配置
客户端再智能也无法绕过服务端缺陷。确保以下基础条件满足：
- 所有节点加入同一集群（
rabbitmqctl join_cluster），且cluster_partition_handling = autoheal或pause_minority - 镜像队列已启用（
x-ha-policy: "all"或指定节点数），避免主节点宕机后消息丢失 - 各节点间网络互通、时间同步、Erlang cookie 一致
- 禁用
loopback_users，允许远程客户端连接
不复杂但容易忽略：故障转移效果取决于客户端重连行为 + 服务端数据冗余 + 网络可达性三者协同。单纯依赖某一层无法真正高可用。
