客户端无法平滑感知新主节点，根本原因是未遵循哨兵“主动轮询+及时重建连接池”的设计逻辑：Jedis需正确配置轮询间隔与masterName，Lettuce须开启自动刷新、认证及连接验证，且所有客户端均面临切换窗口期的状态不一致问题。
客户端无法平滑感知新主节点，根本原因不是哨兵没切成功，而是客户端压根没按哨兵的设计逻辑去用——它不推地址，只等你来问，还要求你问对人、问得勤、问完立刻换连接。
为什么JedisSentinelPool配置了哨兵地址却还是连旧主
很多人以为把哨兵地址塞进JedisSentinelPool构造函数就万事大吉，其实这只是“启动时问一次”。默认情况下，JedisSentinelPool每 2 秒轮询一次哨兵查SENTINEL get-master-addr-by-name，但这个行为受两个关键参数控制：
-
sentinelMonitorInterval：轮询间隔，默认 2000ms；设为 0 则完全关闭自动刷新，等于“只问一次” -
masterName必须和哨兵配置里的sentinel monitor命令中定义的名称严格一致（区分大小写），否则查不到 - 如果哨兵列表只配了一个地址，该哨兵刚好在切换窗口期宕机或网络不通，
get-master-addr-by-name就会失败并 fallback 到缓存的老地址
常见错误是日志里出现Sentinel unreachable但连接池照常复用旧连接，因为Jedis默认不抛异常，只打warn日志并继续用缓存值。
Lettuce启用RedisSentinelConfiguration后仍写失败的三个盲点
Lettuce 的订阅机制比 Jedis 更主动，但它默认不自动重建连接池——即使监听到+switch-master事件，旧连接仍保留在连接池中，新请求可能随机拿到一个指向旧主的连接，报READONLY。
- 必须显式开启
setRefreshPeriod（如 1000ms），否则只在初始化时查一次地址 - 必须设置
setDatabase和setPassword，否则重连时认证失败，连接被标记为invalid但不剔除 - 连接池（
GenericObjectPool）需配置testOnCreate=true+testOnBorrow=true，否则不会在取出连接时验证其是否仍可写
不满足这三条，Lettuce 就只是“听到了消息”，但没“执行动作”。
手动触发SENTINEL failover时客户端为何更难跟上
用SENTINEL failover mymaster强制切换，看起来可控，实则放大客户端感知延迟。因为哨兵在收到命令后，并不会立刻广播+switch-master，而是先走完整个故障转移流程：主观下线→客观下线→选举→配置重写→同步从节点→最后才发事件。整个过程在默认配置下可能耗时 5–12 秒。
- 客户端在这段时间内持续收到
Connection refused或NOAUTH（因新主刚启动，auth未生效或配置未同步） - 若客户端重试策略是指数退避且最大重试次数≤3，大概率在切换完成前就放弃
- 哨兵的
down-after-milliseconds和failover-timeout参数在此类场景下影响极大：前者太小易误判，后者太大导致等待过久
真正可控的做法不是靠failover命令，而是提前调低down-after-milliseconds（如设为 5000），让自然故障也能更快响应，客户端反而更稳定。
生产环境最易被忽略的连接池重建时机
所有客户端库都依赖“获取新地址 → 关闭旧连接 → 建立新连接 → 注入连接池”这一链路，但没人告诉你：这个过程不是原子的。旧连接可能还在处理未完成的命令，新连接已建立，但连接池里新旧混杂。
- JedisSentinelPool 的
destroy方法会逐个关闭连接，但若某连接卡在read timeout，它可能阻塞整个重建流程达数秒 - Lettuce 的
StatefulRedisMasterSlaveConnection在收到+switch-master后会触发refresh，但若此时有大量异步命令正在 pipeline 中，部分命令仍会发往旧主并失败 - Redisson 的
RedisNodesManager虽然支持自动发现，但默认不清理已失效的MasterSlaveEntry，需配合setScanInterval（建议 ≤ 1000）主动轮询
这意味着，哪怕你所有配置都正确，切换瞬间的请求失败仍是大概率事件——不是配置问题，而是分布式系统固有的状态不一致窗口。能做的，是缩短这个窗口，而不是幻想它不存在。
