redis哨兵模式下客户端超时应设为1500–3000ms连接超时和500–1000ms命令超时，重试前须主动调用sentinel get-master-addr-by-name刷新主地址，避免卡死旧节点。
Redis哨兵模式下客户端连接超时经常被设成 0 或过长，导致故障切换时卡死
哨兵模式本身不处理客户端路由，它只负责监控和故障转移。客户端必须自己识别主从变化、重连新主节点。如果 connectTimeout 设为 0（无限等待）或远大于哨兵 failover 时间（通常 30–60 秒），在主节点宕机后，客户端会卡在 TCP 连接阶段，既不失败也不重试，看起来像“假死”。
- Java Jedis 默认
connectTimeout=2000，但很多项目显式覆盖为0或30000，这是高危配置 - Python redis-py 的
socket_connect_timeout同理，设为None就等同于阻塞等待 - 真实环境中建议设为
1500–3000毫秒：足够应对网络抖动，又能在主节点不可达时快速失败
读操作超时必须区分「连接超时」和「命令超时」，且后者要更短
哨兵切换期间，旧主可能已降为从、拒绝写入，但还能响应 PING 或 INFO；此时 connectTimeout 已通过，但 timeout（即 socket read/write timeout）决定命令是否卡住。尤其读操作（如 GET）若设得太长，会在旧从节点上空转，错过新主就绪时机。
- Jedis 中
timeout参数同时控制读/写命令超时，建议设为500–1000ms；不要复用连接超时值 - redis-py 的
socket_timeout同样需独立设置，且应 ≤socket_connect_timeout - 若业务允许读从（sentinel 可配
readonly），需额外确认客户端是否启用READONLY命令 —— 否则读请求仍发给旧主并直接报READONLY错误
重试逻辑不能依赖通用 HTTP 重试库，必须感知哨兵拓扑变更
普通指数退避（如 1s→2s→4s）在哨兵场景下容易放大问题：第一次失败是主宕机，但重试时哨兵还没完成选举，客户端反复连旧地址，直到超时堆满线程。真正有效的重试，必须结合哨兵发现机制。
- 每次连接失败后，强制调用
sentinel get-master-addr-by-name刷新主节点地址，而不是缓存一次用到底 - Jedis SentinelPool 内部会自动刷新，但前提是没禁用
setMaster或手动绕过池子直连Jedis实例 - 自研客户端务必避免在初始化后长期持有
masterHost:port字符串；应封装为 lazy-get 接口，每次操作前查哨兵 - 重试次数建议 ≤ 3 次，间隔固定 300ms 即可 —— 哨兵 failover 通常在 10–20 秒内完成，拖太久没意义
测试故障切换时，别只看「是否连得上」，重点验证命令级行为是否符合预期
很多团队用 PING 成功就认为切换完成，但实际 SET 可能因权限、角色未同步等问题失败。真实验证必须走业务关键路径。
- 模拟主宕机后，立即发一个
SET key value EX 10，观察是否返回OK，而非READONLY或连接拒绝 - 检查客户端日志里是否有重复连接同一旧地址的行为（说明没触发哨兵地址刷新）
- 用
redis-cli -h sentinel-host -p 26379 SENTINEL get-master-addr-by-name mymaster手动比对客户端获取的地址是否一致 - 注意：哨兵默认每 10 秒向客户端推送配置变更，但客户端不主动拉取的话，可能有最多 10 秒延迟 —— 这就是为什么重试前必须主动查
