客户端连接旧主因连接池未重建，需满足多哨兵配置、DNS刷新、主动拉取主地址及写前ROLE校验等条件才能确保切换生效。
客户端在哨兵完成 +switch-master 后仍连旧主，不是哨兵没切成功，而是连接池没真正“动起来”——它可能压根没收到事件、收到了但没重建、或重建了却还在复用旧连接。
为什么 JedisSentinelPool 没触发连接池重建
它不是监听到事件就立刻销毁重连，而要满足一连串隐性条件：
- 必须至少传入两个可达的哨兵地址（
192.168.1.10:26379,192.168.1.11:26379），单点失效后轮询直接失败 - 日志里搜不到
Discovered new master，基本可断定没订阅上__sentinel__:hello频道（常见于防火墙拦 26379、哨兵间通信异常、或客户端配了localhost） - 即使收到事件，JedisSentinelPool 默认只调用
sentinel get-master-addr-by-name，但如果返回的 IP:port 和当前池里存的一致，它会跳过重建——哪怕那个地址已下线 -
setTestOnBorrow(true)必须显式调用，否则 PING 不触发连接校验，更不会引发重建逻辑
如何验证并强制刷新 DNS 与连接池缓存
DNS 永久缓存和连接池中存活的 ESTABLISHED 连接，是导致请求持续打向旧 IP 的两大隐形原因：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- JVM 默认
sun.net.inetaddr.ttl = -1（永久缓存），启动时加参数-Dsun.net.inetaddr.ttl=30，让 DNS 每 30 秒刷新一次 - 对 JedisSentinelPool，不能只等自动重建；一旦确认拓扑变更（如日志出现
+switch-master），立即调用pool.destroy()再 new 一个新实例 - 对 Lettuce，不要长期持有
StatefulRedisConnection实例；每次写前执行connection.sync().ping()，失败则调用RedisClient.connect()新建连接 - K8s 环境下还要检查
kubectl get endpoints redis-master，确保 Service 的 endpoints 已更新，否则 DNS 解析再准也连不到真实节点
ROLE 命令校验必须加在写操作前
testOnBorrow=true 只能拦住宕机节点，拦不住已降级为从的旧主——PING 成功，但 SET 必然报 READONLY You can't write against a read only replica：
- 每次发写命令前，先执行
ROLE，解析返回值：若首项是"slave"，说明连接指向副本，立刻丢弃该连接 - 避免用
INFO replication，格式不稳定；ROLE是 Redis 官方保证结构一致的命令 - 给连接加
lastRoleCheckAt时间戳，超 30 秒未检就强制重查，防止因心跳间隔长导致误判
兜底：定期主动拉取权威主节点地址
当事件监听不可靠（比如网络抖动丢消息、哨兵版本低不广播完整信息），仅靠 __sentinel__:hello 就不够：
- 每 5–10 秒主动调用
SENTINEL get-master-addr-by-name mymaster（注意：不是信消息里的 IP，而是拿这个命令的返回值） - 拿到新地址后，必须创建全新连接池实例，并原子切换业务层引用；改
connection_pool.connection_kwargs不生效 - Lettuce 用户注意：
RedisClient.setUri()不刷新已有连接，必须重建StatefulRedisConnection - 别忽略超时控制：拉取失败时保留上次有效地址，避免全量请求直接熔断
最常被忽略的是：连接池重建 ≠ 连接自动失效。旧连接只要 TCP 还 ESTABLISHED，就可能继续发命令——哪怕新池已建好。业务层必须配合角色校验或连接生命周期管理，否则“刷新”只是纸面功夫。
