根本原因是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 实例引用，依然会往旧地址发命令。这两层缓存不破，自动发现永远是纸面功能。
