缓存击穿风险需通过三类敏感指标提前感知：单个key未命中率连续30秒超80%、热点key TTL趋近于0、同一key并发请求量陡升；全局命中率易掩盖局部问题，须结合应用层埋点与锁竞争监控实现精准干预。

缓存击穿事故往往在毫秒级内爆发，靠事后排查来不及；关键得在 key 过期前就感知风险，用指标驱动干预。

监控哪些 Redis 指标最能暴露击穿风险

不是所有指标都有效。真正敏感的是三类：缓存未命中率突增、热点 key 的 TTL 剩余时间趋近于 0、同一 key 的并发请求量陡升。

• keyspace_hits 和 keyspace_misses 的比值——单个 key 的未命中率连续 30 秒 > 80%，大概率已过期或即将过期
• TTL 命令返回值 key 数量——比如商品详情 product:1001 TTL 剩 5 秒，且被每秒 200+ 次访问，就是高危信号
• 应用层打点的「同一 key 并发查询 DB 次数」——若 1 秒内对 user:9999 触发了 50 次数据库查询，说明锁没生效或没加锁

如何用 Prometheus + Grafana 实时告警

直接查 redis-cli 不现实，得靠 exporter 抓取并做聚合计算。重点不是看平均值，而是盯住 P99 和突刺。

Redis Skill - 高性能缓存管理

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

下载

• 配置 redis_exporter 采集 redis_keyspace_hits_total 和 redis_keyspace_misses_total，按 key 标签分组（需开启 Redis 的 latency-monitor-threshold 并配合 slowlog）
• Grafana 中建面板：公式 rate(redis_keyspace_misses_total{job="redis"}[1m]) / (rate(redis_keyspace_hits_total{job="redis"}[1m]) + rate(redis_keyspace_misses_total{job="redis"}[1m]))，阈值设为 0.7
• 告警规则里加条件：redis_db_keys{db="0"} == 0 且 redis_key_expires_total{job="redis"} > 0，表示该库有 key 即将集体失效

为什么只看命中率会漏掉真实风险

全局命中率可能稳定在 95%，但某个 key 已经连续 10 分钟未命中——它被淹没在统计里了。击穿是局部现象，不是系统级问题。

• Redis 自带的 INFO keyspace 只返回每个 db 的汇总数据，不暴露单个 key 的 TTL 或访问频次
• 必须配合应用层埋点：在缓存读取逻辑里记录 cache.get("order:123") 是否 miss，再上报到 metrics 系统
• 如果用 Redisson，可监听 RLock.tryLock() 失败次数——失败多说明锁竞争激烈，背后可能是 key 刚过期

指标异常后怎么自动干预

告警不能只发钉钉，得触发动作。最有效的不是扩容 DB，而是提前续期或降级。

• 检测到 product:8888 TTL 50，自动执行 EXPIRE product:8888 3600 延长过期时间（前提是业务允许）
• 若发现某 key 在 5 秒内触发 3 次以上 DB 查询，自动切换到本地缓存（如 Caffeine）兜底，避免雪崩式穿透
• 结合 Sentinel 的 sentinel master mymaster 状态，当主节点延迟 > 500ms 时，暂停所有非核心 key 的缓存更新，保主链路

真正难的不是采集指标，而是把「某个 key 的 TTL 剩 3 秒」和「它正被 200 个线程争抢重建」这两件事关联起来——这需要应用层日志、Redis 指标、锁状态三者打标对齐，否则监控永远在追着事故跑。