Redis健康检查必须基于协议层PING命令而非TCP连通性，K8s应使用exec探针调用redis-cli，Spring Boot需增强超时与集群校验，监控需对齐Sentinel/Cluster心跳时间窗口。
Redis 自身不提供 HTTP health endpoint，得靠外部机制实现
Redis 服务进程本身没有内置 /health 这类 REST 接口，它只暴露 TCP 端口（默认 6379）和底层协议命令。所谓“开启 health 探测点”，本质是让外部系统能可靠判断 Redis 实例是否可响应有效请求，而不是单纯端口通不通。
常见错误是只用 telnet 127.0.0.1 6379 或 nc -zv 做 TCP 连通性检查——这只能说明端口没被防火墙拦住，但 Redis 进程可能已卡死、OOM、陷入无限阻塞或主从同步积压导致实际无法处理命令。
- 必须走协议层探测：发
PING命令并等待PONG响应，这才是 Redis 官方认可的健康信号 - 单次
PING不够：网络抖动或瞬时过载可能导致偶发失败，监控系统需支持重试与连续失败阈值（如 3 次失败才标记为不健康） - 集群场景更复杂：不能只查一个节点，要确认分片槽（slot）映射完整、各节点
CLUSTER NODES状态为connected且无fail标记
Kubernetes 中 livenessProbe / readinessProbe 怎么配才不误杀
在 K8s 里用 tcpSocket 探针最省事，但风险极高——它完全绕过 Redis 协议，只要端口开着就认为健康，线上出过多次“Redis OOM 后仍能 accept 连接但拒绝所有命令”的事故。
正确做法是改用 exec 探针执行 redis-cli：
livenessProbe:
exec:
command:
- sh
- -c
- "timeout 3 redis-cli -h 127.0.0.1 -p 6379 PING | grep -q PONG"
initialDelaySeconds: 30
periodSeconds: 15
timeoutSeconds: 3
failureThreshold: 3
-
timeout 3防止redis-cli卡死拖垮整个探针周期 -
failureThreshold: 3避免因瞬时 GC 或慢查询导致的误重启 - 不要省略
-h和-p：容器内redis-cli默认连127.0.0.1:6379，但若 Redis 配置了bind或protected-mode yes，本地回环可能被拒绝 -
readinessProbe的initialDelaySeconds应比livenessProbe更短（如 5 秒），确保主从同步完成后再接入流量
Spring Boot Actuator 的 RedisHealthIndicator 为什么有时返回 UP 却实际不可用
Spring Boot 的 RedisHealthIndicator 默认只做一次 connection.ping()，看似合理，但在高并发或连接池复用场景下会掩盖真实问题。
- 它复用的是连接池里的空闲连接，而连接池可能缓存了已断开但未检测的 socket（即“连接假死”）
- 如果 Redis 正在执行
KEYS *或FLUSHALL这类阻塞操作，PING会被排队，超时前仍返回UP - 集群模式下，它只检查配置的 connection factory 所指向的单个节点，不验证 slot 分布或从节点状态
改进方式是在自定义 HealthIndicator 中加入：redisTemplate.execute((RedisCallback，并显式设置 timeout 参数；对集群部署，还需调用 cluster.getClusterNodes() 检查节点列表完整性。
Redis Sentinel 和 Cluster 自带的健康发现机制怎么跟你的监控对齐
Sentinel 和 Redis Cluster 内部都有心跳机制（Sentinel 用 INFO + PING，Cluster 用 PING-PONG gossip），但它们的“主观下线”“客观下线”判定标准和你的监控告警阈值很可能不一致。
- Sentinel 的
down-after-milliseconds默认 30000ms，而 Prometheus 抓取间隔常设为 15s——你可能在 Sentinel 还没标记节点 down 时，监控图表已持续红了两分钟 - Cluster 的
cluster-node-timeout默认 15000ms，但节点被标记fail需要半数以上节点投票；你的告警规则若只看单个节点cluster_state:fail，可能比集群实际故障转移早触发 2–3 分钟 - 关键动作：把 Sentinel 的
sentinel masters输出和 Cluster 的CLUSTER INFO解析结果，作为监控数据源之一，而非仅依赖客户端上报的连接状态
真正容易被忽略的是：所有自动探测都依赖时间窗口对齐。比如 K8s periodSeconds: 15、Sentinel down-after-milliseconds 30000、Prometheus scrape_interval 15s，三者节奏错开会导致“监控说挂了，但哨兵还没切主，应用日志也没报错”——这种时间差必须在告警规则里显式建模，不能只设静态阈值。
