根本原因是客户端未正确配置哨兵地址；必须使用sentinel.conf中sentinel monitor定义的哨兵监听地址（如127.0.0.1:26379），而非redis主节点地址，且需确保网络可达、大小写敏感匹配mastername、至少配置2个哨兵地址。
客户端连接哨兵集群时，为什么总连不上主节点？
根本原因不是哨兵没启动，而是客户端压根没正确配置哨兵地址——它需要的是 sentinel.conf 里 sentinel monitor 那行定义的哨兵监听地址（通常是 127.0.0.1:26379），而不是 Redis 主节点的地址。JedisSentinelPool 和 Lettuce 都靠轮询这些哨兵来获取当前主节点 IP+端口，一旦填错或漏掉任意一个哨兵地址，就可能卡在“找不到主”状态。
常见错误现象：
- JedisConnectionException: Could not get a resource from the pool
- Lettuce 日志反复打印 Unable to connect to [127.0.0.1:6379]（连的是旧主地址，不是哨兵）
- 客户端启动后能连上，但主从切换后写操作立刻失败
- 哨兵地址必须是客户端网络可达的 IP+端口，不能写
localhost（容器/跨主机场景必挂） - 至少提供 2 个哨兵地址，避免单点故障导致初始化失败
- JedisSentinelPool 构造时传入的
masterName必须和哨兵配置中sentinel monitor <master-name></master-name>的值完全一致（大小写敏感） - Lettuce 的
RedisURI要用redis-sentinel://协议，例如：redis-sentinel://10.0.1.10:26379,10.0.1.11:26379/redis-master
JedisSentinelPool 初始化后，主节点变更为何不生效？
因为 JedisSentinelPool 默认只在初始化时拉一次主节点信息，之后全靠内部定时任务轮询哨兵更新。这个任务默认 2 秒执行一次，但有个致命限制：如果哨兵返回的主节点地址和当前连接池里的一致，它就不刷新连接池——哪怕那个主节点已经宕机了。
所以你看到的现象是：主挂了，哨兵已选举新主，但 Jedis 还在往旧 IP 发请求，直到超时或报错才触发重试逻辑，期间大量请求失败。
- 必须显式开启自动发现：设置
setTestOnBorrow(true)或setTestOnReturn(true)，让每次借连接前 ping 一下，失败则触发reset - 调大
sentinelMonitorInterval（默认 2000ms）反而更稳，避免频繁轮询干扰哨兵；但别超过 5000ms，否则故障感知太慢 - 务必关闭
testWhileIdle—— 它会定期 ping 空闲连接，但 Jedis 在 ping 失败后不会自动重建整个连接池，只会丢弃该连接，容易造成连接数持续下降 - 连接池
maxTotal建议设为 32~64，太大反而加剧故障期间的连接堆积
Lettuce 的 RedisClient 如何确保故障转移后写操作不中断？
Lettuce 天然支持拓扑刷新，但默认策略偏保守：只有当连接异常断开时才重新向哨兵查主节点，而不会主动探测主是否健康。这意味着，如果主节点假死（TCP 连接未断但命令超时），Lettuce 可能继续往它发请求，直到 socket read timeout 触发重连。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实使用中，必须手动启用主动监控机制，否则高可用形同虚设。
- 启用
DynamicNodeLocator：在RedisURI中添加参数?refreshPeriod=3000，强制每 3 秒从哨兵拉一次拓扑 - 设置
timeoutOptions：用TimeoutOptions.enabled()开启命令级超时，防止个别慢请求拖垮整个连接 - 禁用
pingBeforeActivateConnection（默认 false）—— Lettuce 5.3+ 已废弃该选项，留着反而引发连接复用异常 - 若用 Spring Boot，确认
spring.redis.sentinel.master和spring.redis.sentinel.nodes配置正确，且spring.redis.lettuce.cluster.refresh.period不为 0
为什么本地测试通，上线后哨兵连接频繁超时？
本质是网络策略问题：哨兵之间、客户端与哨兵之间、哨兵与 Redis 实例之间，三组通信必须全部打通。最容易被忽略的是哨兵与 Redis 实例之间的反向通信——哨兵需要能主动连上 Redis 的 port（如 6379）和 sentinel-port（如 26379），否则它无法执行 SENTINEL is-master-down-by-addr 等指令，也就无法完成故障转移。
线上环境常因安全组、iptables 或 Kubernetes NetworkPolicy 拦截了这部分流量，导致哨兵认为“主还活着”，客户端却连不上，陷入僵局。
- 检查哨兵日志是否有
+sdown master但无+odown master—— 这说明多数哨兵没达成共识，大概率是网络不通 - 在客户端机器上执行：
telnet <sentinel-ip> 26379</sentinel-ip>和telnet <redis-ip> 6379</redis-ip>，两个都必须通 - 确认哨兵配置中的
bind和protected-mode no已生效，否则它只监听 127.0.0.1 - 容器部署时，哨兵的
sentinel announce-ip必须设成宿主机或 Service 可达的地址，不能依赖自动发现
哨兵模式的可靠性不取决于配置多华丽，而在于每一跳通信是否真正可达。少一个 telnet 通，就少一分确定性。
