缓存击穿这类高风险问题，最好不要等到故障发生后才被动发现。通常需要重点盯紧三类敏感信号：单个key的未命中率连续30秒超过80%、热点key的TTL已经接近0、同一key的并发请求量突然升高。若只观察全局命中率，很多局部异常往往会被整体数据“稀释掉”。真正有效的方式，是结合应用层埋点与锁竞争监控，尽早识别风险并进行精准干预。
缓存击穿事故通常会在毫秒级内快速爆发，依赖事后排查往往为时已晚；关键在于要在 key 过期之前就提前感知风险，并通过 Redis 监控指标驱动自动化干预。
监控哪些 Redis 指标最能暴露击穿风险
并不是所有 Redis 指标都具备判断价值。真正对缓存击穿预警最敏感的，通常是三类：缓存未命中率突然上升、热点 key 的 TTL 剩余时间接近 0、同一 key 的并发请求量明显陡增。
keyspace_hits和keyspace_misses的比值——如果单个key的未命中率连续 30 秒 > 80%，大概率说明该 key 已经过期，或正处于即将过期的危险阶段TTL命令返回值 < 60 秒的热点key数量——例如商品详情product:1001的 TTL 只剩 5 秒，同时每秒仍有 200+ 次访问，这就是非常典型的高危预警信号- 应用层打点的「同一
key并发查询 DB 次数」——如果 1 秒内对user:9999触发了 50 次数据库查询，通常说明互斥锁未生效，或者根本没有加锁保护
如何用 Prometheus + Grafana 实时告警
仅靠 redis-cli 手动排查并不现实，更适合通过 exporter 抓取指标并进行聚合分析。监控重点也不应停留在平均值，而应该重点盯住 P99、瞬时突刺和异常波动。
- 配置
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:8888TTL < 10 秒且访问 QPS > 50，自动执行EXPIRE product:8888 3600延长过期时间（前提是业务场景允许这样做） - 如果发现某个
key在 5 秒内触发 3 次以上 DB 查询，可自动切换到本地缓存（如 Caffeine）进行兜底，避免出现雪崩式穿透 - 结合 Sentinel 的
sentinel master mymaster状态，当主节点延迟 > 500ms 时，暂停所有非核心key的缓存更新操作，优先保障核心主链路稳定
难点从来不在于“把 Redis 指标采集上来”，真正棘手的是，如何把「某个 key 的 TTL 只剩 3 秒」与「它此刻正被 200 个线程同时争抢重建」这两件事准确关联起来分析——这要求必须把应用层日志、Redis 监控指标和锁状态进行统一打标，并严格对齐时间线。否则监控系统看到的永远只是结果，无法真正做到在缓存击穿事故发生前提前预警。
