根本原因是jedissentinelpool未真正启用自动发现机制；必须显式设置settestonborrow(true)、传入至少两个可达哨兵地址、调大sentinelmonitorinterval，否则轮询不触发重建且dns/连接复用导致持续连旧主。

客户端不更新主节点地址，根本不是哨兵没切成功，而是 JedisSentinelPool 没真正“活”起来——它初始化后默认只在内部轮询时被动响应，且轮询逻辑有隐藏前提：必须先连得上哨兵、能收到 +switch-master 事件、并主动验证新主角色，三者缺一不可。

为什么 JedisSentinelPool 初始化后不自动刷新主节点

JedisSentinelPool 构造完只是“记住了哨兵地址”，并不立即拉取主节点；它依赖后台定时任务（默认每 2 秒）调用 sentinel get-master-addr-by-name 查询。但这个查询有关键限制：

• 如果哨兵返回的 IP:port 和当前连接池里存的一致，它就跳过重建连接池——哪怕那个地址已宕机
• 若哨兵列表中只有一个可达，而该哨兵恰好没同步到最新拓扑（如网络延迟或选举未完成），查询结果就是旧地址
• 它不会主动 ping 当前主节点做健康检查，除非你显式开启 testOnBorrow 或 testOnReturn

如何确认 +switch-master 事件是否被正确接收

哨兵通过 Pub/Sub 在 __sentinel__:hello 频道广播变更，JedisSentinelPool 内部会订阅该频道。但订阅失败很常见：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 日志里搜不到 Discovered new master，基本可断定事件丢失
• 哨兵之间通信异常（quorum 值配置过大、哨兵数不足、防火墙阻断 26379 端口）会导致事件无法全量传播
• 客户端与哨兵网络不通，或配置了 localhost（容器/跨主机场景下 DNS 解析为 127.0.0.1，实际连不上）
• JVM 的 sun.net.inetaddr.ttl 为 -1（永久缓存），导致即使哨兵返回新 IP，DNS 解析仍指向旧地址

JedisSentinelPool 必须启用的三项实操配置

光靠构造函数传参远远不够，以下三项必须显式设置，否则自动发现形同虚设：

• 调用 pool.setTestOnBorrow(true)：每次 getResource() 前执行 PING，失败则触发连接池重置逻辑
• 构造时传入至少两个哨兵地址，且确保它们都监听在客户端可访问的真实 IP 上（禁用 localhost）
• 设置 pool.setSentinelMonitorInterval(3000)（3 秒），避免太短引发哨兵压力，也避免太长导致故障感知滞后

连接池重建失败的典型表现与绕过方式

即使收到 +switch-master，JedisSentinelPool 也可能卡在“想重建却建不出来”的状态：

• 现象：日志出现 Could not get a resource from the pool，但新主节点 telnet 通、redis-cli -h 新IP -p 新端口 ping 返回 PONG
• 原因：连接池 maxTotal 被占满，或 testWhileIdle 开启后不断丢连接却不重建池
• 应急操作：捕获 JedisConnectionException 后，手动调用 pool.destroy() 再重新 new 一个 JedisSentinelPool
• 长期建议：关闭 testWhileIdle，改用 testOnBorrow + 合理的 maxWaitMillis（建议 2000ms）

最易被忽略的是 DNS 缓存和连接复用——哪怕哨兵返回了新 IP，JVM 还在用旧解析结果建连；哪怕连接池重建了，上层代码若缓存了 Jedis 实例引用，依然会往旧地址发命令。这两层缓存不破，自动发现永远是纸面功能。