如何通过Redis指标监控预防缓存击穿事故？

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

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

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

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

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

如何用 Prometheus + Grafana 实时告警

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

1. 配置 redis_exporter 采集 redis_keyspace_hits_total 和 redis_keyspace_misses_total，按 key 标签分组（需开启 Redis 的 latency-monitor-threshold 并配合 slowlog）
2. 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
3. 告警规则里加条件：redis_db_keys{db="0"} == 0 且 redis_key_expires_total{job="redis"} > 0，表示该库有 key 即将集体失效

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

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

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

指标异常后怎么自动干预

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

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

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