Redis缓存穿透与雪崩的监控指标有哪些？-Redis-PHP中文网

缓存穿透和雪崩需组合判断：穿透看keyspace_misses持续飙升+keyspace_hits极低（如归零），雪崩看命中率1–5分钟内从95%+骤降至30%以下且misses同步激增，单指标易误判。

redis缓存穿透与雪崩的监控指标有哪些？

缓存穿透和雪崩的监控不能只看一个指标，必须组合判断——单独看命中率可能误判，只盯数据库QPS又太滞后。

穿透的本质是“查不到还反复查”，所以核心是识别无效请求是否被拦截、是否打到了库。

keyspace_misses 持续飙升 + keyspace_hits 极低（比如 instantaneous_ops_per_sec 并未明显增长 → 可能是大量非法 key 导致 miss，需结合业务日志确认
应用层埋点中 cache_miss_null_count（缓存 miss 且 DB 返回 null 的次数）突增，且对应 key 不在布隆过滤器白名单里 → 穿透已发生
数据库慢查询日志中出现大量 SELECT ... WHERE id = ?，参数为负数、超大 ID 或 UUID 格式错误 → 典型恶意穿透特征
connected_clients 稳定，blocked_clients 无变化，但 used_memory 增长缓慢 → 说明没写入有效数据，不是击穿或雪崩，更倾向穿透

雪崩是系统性失效，指标变化剧烈且多维同步异常，不能只看命中率断崖下跌。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

keyspace_hits 归零或接近 0，keyspace_misses 在 1–5 分钟内翻 5 倍以上 → 首要信号，但必须配合其他指标交叉验证
connected_clients 骤降至 0 或极低值 → 很可能是 Redis 重启后客户端未重连，或连接池耗尽，属于服务级雪崩前兆
cluster_state:ok 为 fail，或 cluster_slots_assigned ≠ 16384 → 集群级故障，比单 key 过期更危险
loading:1 持续存在（INFO persistence 查看）→ RDB/AOF 加载中，期间所有读请求必 miss，极易触发雪崩
应用日志中连续出现 cache miss rate: 100%，且伴随 query_database 调用耗时 > 1s → 穿透已成事实，不是预警而是确认

标准化监控工具容易漏掉关键上下文：

Prometheus 抓取 keyspace_hits 是聚合值，如果采集周期设为 30s，可能错过 10s 内的断崖下跌
告警规则若只设 cache_hit_rate ，会忽略“从 98% → 40% → 95%”的抖动，也覆盖不了“局部 DB 实例被打爆但 Redis 指标正常”的情况
evicted_keys 突增常被误认为内存问题，实际可能是雪崩导致大量空值写入+淘汰，掩盖了根本原因
真正有效的判断往往来自三处实时交叉：Redis INFO stats + 应用 tail -f application.log | grep "cache miss" + 数据库 SHOW PROCESSLIST 查阻塞连接

复杂点在于，穿透和雪崩在初期指标有重叠（比如都表现为高 miss），但根因完全不同：一个是“不该进来的进来了”，一个是“该在的全没了”。监控时最容易忽略的是时间粒度和上下文关联——等告警发出来，通常已经穿透或雪崩了。