redis-cli ping超时但服务正常，问题通常出在哨兵与目标节点间的链路：先验证哨兵端口26379和主节点6379直连是否通，再排查网络可达性、哨兵cpu负载、连接数限制、配置未生效、info响应延迟及日志跳变等根因。
redis-cli ping 返回超时但服务实际在运行
这种情况大概率不是 Redis 本身挂了，而是哨兵（Sentinel）在发 PING 时没收到响应，触发了 down-after-milliseconds 判定逻辑。别急着改哨兵配置，先确认底层是否真“通”。
用 redis-cli -p 26379 ping 连哨兵端口，看是否能秒回 PONG；再用 redis-cli -h -p 6379 ping 直连主节点验证——两者都通，说明 Redis 实例活着，问题出在“哨兵→目标节点”链路上。
- 网络层：用
telnet 6379或nc -zv 6379测试端口可达性，注意跨机房场景下防火墙可能只放行客户端端口，未放行哨兵到数据节点的通信 - CPU 负载：哨兵自身是单线程事件循环，
top -p $(pgrep -f "redis-sentinel")查看其 CPU 占用；若持续 >80%，说明哨兵忙于处理其他任务（比如大量订阅消息、频繁重连），PING 命令被延迟发送或丢弃 - 系统连接数：哨兵默认每个监控节点维持一个 TCP 连接，若监控 20 个主从+10 个其他哨兵，连接数轻松破百；
ss -ant | grep :26379 | wc -l查看当前 ESTABLISHED 连接数，接近系统net.core.somaxconn限制时会静默拒绝新连接
SENTINEL CONFIG GET 返回值与配置文件不一致
哨兵不会自动 reload 配置文件，改完 sentinel.conf 后不重启或不调用 SENTINEL CONFIG SET，运行时值就是旧的。尤其容器化部署时，常误以为挂载配置就生效了。
查运行时真实值必须走命令行：redis-cli -p 26379 SENTINEL CONFIG GET mymaster down-after-milliseconds。返回空或报错，说明该 master 名字不存在——常见于 sentinel monitor mymaster 127.0.0.1 6379 2 中名字拼错，或哨兵根本没成功连接上主节点（INFO 拉取失败）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认监控关系：执行
SENTINEL MASTER mymaster，看是否有num-slaves和flags字段；若 flags 包含disconnected或odown，说明哨兵连不上主节点，PING 自然发不出去 - 检查 INFO 拉取：哨兵每 10 秒发一次
INFO，若主节点INFO响应慢（如阻塞在 RDB/AOF 重写），会导致后续 PING 延迟发送；用redis-cli info | grep used_memory看主节点内存是否突增，间接判断是否在持久化 - 日志定位：哨兵日志里搜
+sdown或-sdown，配合时间戳看是否集中爆发，如果是，大概率是网络抖动或目标节点瞬时卡顿，而非配置错误
哨兵日志刷屏 “+sdown master mymaster” 和 “-sdown master mymaster” 来回跳变
这是典型的 down-after-milliseconds 设得太小，叠加网络抖动导致的误判。哨兵每 100ms 左右检查一次，但判定依据是“当前时间 − 最后一次有效响应时间 > 阈值”，只要中间有一次 PONG 晚到，立刻 SDOWN；下一秒又收到 PONG，立刻取消。
不要直接调大这个值来治标，先压测验证真实延迟：redis-benchmark -h -p 6379 -t ping -n 1000 -q 看平均延迟；再用 redis-cli -p 26379 SENTINEL SENTINELS mymaster 查其他哨兵是否也出现同样跳变——如果只有某一台哨兵跳，说明它所在机器负载高或网络差，不是全局问题。
- 局域网环境建议设为
3000～5000，避免把100ms级别的瞬时延迟当故障 - 跨机房部署必须设 ≥
10000，否则一次 TCP 重传（通常 1s 起）就能触发 SDOWN - 切记：多个哨兵实例配置相互独立，改完一个得挨个检查，不能只改 leader 哨兵
Redisson 或 Spring Boot 连接 Sentinel 时提示 “GET-MASTER-ADDR-BY-NAME timeout”
这个超时不是 Redis 数据节点的问题，而是客户端连哨兵查询主节点地址时卡住了。Redisson 默认用 3000ms 调用 SENTINEL GET-MASTER-ADDR-BY-NAME，Spring Boot 的 spring.redis.sentinel.timeout 控制的也是这一步。
重点排查哨兵自身的响应能力：用 redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster 手动执行，看是否秒回。如果手动也慢，说明哨兵内部有瓶颈；如果手动快但客户端慢，检查客户端到哨兵的网络（尤其是 TLS 握手耗时）。
- 哨兵性能瓶颈常见于：监控节点过多（>50）、启用了
sentinel auth-pass但密码校验慢、磁盘 I/O 高导致日志写入阻塞事件循环 - Redisson 推荐升级到 3.23.0+，修复了哨兵地址缓存失效后并发重试导致的雪崩问题
- Spring Boot 若用 Lettuce，注意
spring.redis.lettuce.sentinel.timeout是连接哨兵的超时，和spring.redis.sentinel.timeout（Jedis）不是一回事，别配错位置
SENTINEL MASTER 输出里的 last-ping-reply 和 last-ok-ping-reply 时间差，比死磕配置值更能定位根因。
