根本问题是客户端未动态刷新主节点地址，仍向已下线旧主重试；须启用JedisSentinelPool、显式设置testOnBorrow(true)、传入至少两个可达哨兵地址、调大sentinelMonitorInterval，并监听+switch-master事件重建连接池。
哨兵切换期间客户端连不上新主节点怎么办
根本问题不是“连不上”，而是客户端还在用旧的 master 地址重试。哨兵完成故障转移后，新主节点的 IP 和端口已经变了，但老客户端没刷新——它会持续向已下线的旧地址发请求，超时、重试、堆积线程，最终拖垮连接池，把短暂抖动放大成数据库雪崩。
必须让客户端主动感知变更，而不是靠轮询或重启。关键动作有三步：
- 初始化时调用
sentinel get-master-addr-by-name mymaster拉取当前主节点地址，而不是写死127.0.0.1:6379 - 启动一个后台线程，定期（比如每 5 秒）执行该命令，比对结果是否变化；一旦发现地址不同，立即重建连接池并丢弃旧连接
- 驱动层需支持自动重定向：Jedis 要用
JedisSentinelPool，redis-py 要用SentinelConnectionPool，不能直接 new Jedis()
为什么 Jedis 的默认 timeout=0 会导致线程卡死
这是生产环境最常踩的坑：timeout=0 表示无限等待 socket 响应。当哨兵刚切完主，旧 master 已关机，但客户端仍往那个地址发命令——TCP 连接建立失败要等系统级超时（Linux 默认 75 秒），期间线程被 getResource() 卡住，连接池满后所有后续请求排队，应用整体 hang 住。
实操必须显式设值：
-
connectionTimeout=2000：建连超过 2 秒直接失败 -
soTimeout=1000：命令响应超过 1 秒就抛JedisConnectionException -
maxRetries=2：最多重试 2 次，避免在切换窗口期反复打错地址 - 禁用
blockWhenExhausted=true，改用fairness=true防止饥饿
哨兵模式下如何避免客户端重试加剧 DB 压力
故障转移本身只要 20–30 秒，但若客户端在这一窗口期内盲目重试缓存查询，且缓存未命中就直查 DB，就会把原本可恢复的抖动变成压垮数据库的洪峰。
核心是加一层“熔断+降级”开关：
- 监听哨兵的
+switch-master事件（通过PUBLISH/SUBSCRIBE），一收到就触发本地熔断器开启，持续 60 秒 - 熔断期间，所有缓存读操作直接返回空或兜底数据，不查 DB；写操作走异步队列暂存
- 配合空值缓存：对查不到的 key，也写入
cache_key:empty并设 TTL=60 秒，防止穿透 - 不要依赖“重试成功即恢复”，而要以“服务可用性”为第一目标，宁可少缓存，不可压垮 DB
集群与哨兵混用时最容易忽略的兼容点
有些团队在哨兵之上又套了 Twemproxy 或自研路由层，以为能提升容灾能力，结果反而引入单点和协议不兼容问题。
真实限制很硬：
- Twemproxy 不支持
SENTINEL命令，无法获取主节点变更，永远连旧地址 - 客户端若用了
redis-cli --cluster类工具管理，会误判哨兵集群为 Cluster 模式，报CLUSTERDOWN - Java 应用里同时引入
jedis和lettuce，若配置混用（如 Jedis 连哨兵、Lettuce 连 cluster），DNS 缓存可能互相污染 - 所有哨兵节点的
sentinel monitor配置中，quorum值必须一致，否则投票无法达成，failover 失败但无明确错误日志
哨兵不是“多加几个进程就高可用”，它的容灾效果完全取决于客户端是否真正适配了它的发现机制——地址动态拉取、连接及时重建、超时严格控制，这三件事漏掉任何一件，故障转移就等于没发生。
