击穿隐患可通过keyspace_misses突增与instantaneous_ops_per_sec分布偏斜定位：若某分钟misses涨3倍而总QPS未明显上升，说明流量集中于少数key，极大概率是热点key刚过期引发的击穿。
直接看 keyspace_misses 突增 + instantaneous_ops_per_sec 分布偏斜，就能定位击穿隐患点
查哪个指标能暴露“热点Key刚过期”的瞬间
击穿不是缓存整体失灵，而是单个 key 在失效那一秒被并发猛砸。所以不能只看全局命中率——keyspace_hits / (keyspace_hits + keyspace_misses) 掉了 5%，可能只是某几个 key 拖累的，得下钻到 key 级别。
关键命令是：redis-cli --scan --pattern "your:prefix:*" | xargs -I{} redis-cli debug object {} 2>/dev/null | grep -E "(refcount|lru)"，配合 redis-cli info stats | grep keyspace_misses 做时间对齐。如果某分钟内 keyspace_misses 涨了 3 倍，而同一时段 instantaneous_ops_per_sec 并没明显上升，说明流量集中在少数 key 上，极大概率是击穿前兆。
注意：别依赖 redis-cli monitor 实时抓包，线上大促时它本身就会拖慢 Redis。
怎么识别“高危热点Key”而不是普通 miss
一个 key 是不是击穿风险点，不取决于它多热，而取决于它“失效后首次加载是否扛得住”。重点关注三类 key：
-
feature:switch:*类开关控制 key（哪怕 QPS 只有 20，失效后查全量配置表也可能锁表） -
rule:antifraud:*类风控规则 key（SQL 复杂、无索引、易慢查询） -
product:detail:*类商品详情 key（QPS > 1000 且 TTL 固定为 3600）
用 redis-cli --bigkeys 扫不出击穿风险，但它能帮你排除大 key 干扰；真正要跑的是自定义脚本，统计每个 key 的 ttl 剩余时间 + 近 5 分钟 GET 请求频次，筛选出 “TTL 500” 的组合。
为什么不能只靠“加锁”就认为安全了
互斥锁（比如 SET key value EX 30 NX）能防并发回源，但掩盖了一个更致命的问题：锁等待时间本身会放大延迟。如果数据库加载耗时 P99 是 420ms，而下游超时设的是 500ms，那锁住的请求里有相当比例会超时失败。
实操建议：
- 所有加锁逻辑必须带 fallback 超时（例如锁等待 > 100ms 就放弃，走空值或降级）
- 监控项必须包含
cache_load_p99_ms（从 DB 查 + 写回 Redis 的整条链路），而不是只看 Redis 命中率 - 对
config:*类低频更新 key，优先用“定时刷新 + 逻辑过期”，而非等失效后抢锁
击穿隐患最常藏在“看起来很稳”的 key 里——它们 TTL 固定、更新极少、QPS 中等，但一旦失效，加载逻辑却没压测过。复盘时盯住 keyspace_misses 时间序列的毛刺，再交叉比对 DB 慢查询日志里的 SQL 模板，才能真正把隐患挖出来。
