排查缓存击穿需三重验证：命中率骤降与GET耗时尖峰并存、DB慢查询中同一热点key高频重复出现、多个key TTL集中归零且与批量操作时间重合。
排查缓存到期后回源瞬时并发击穿，核心是定位“谁在什么时候、以多大并发量，集中访问了哪个即将过期的热点 Key”。这不是靠猜，而是靠监控信号+时间对齐+请求特征三者交叉验证。
看缓存命中率与 Redis GET 耗时毛刺
命中率突然从 98%+ 掉到 60%～70%，同时 Redis 的 get 命令平均耗时出现明显尖峰（比如从 0.3ms 跳到 40ms+），但 Redis 内存、CPU、连接数本身没爆——这说明不是 Redis 性能瓶颈，而是大量请求在等同一个 Key 的重建结果。重点盯住毛刺发生时刻前后 1～2 秒的请求日志和监控曲线。
查数据库慢查询里的重复 ID 和空查模式
击穿发生时，MySQL 慢查询里会密集出现同一张表、同一种 SQL（如 SELECT * FROM product WHERE id = ?），且这些 ? 的值高度集中（比如全是 10001、10002 这类热门商品 ID）。更关键的是：这些 ID 在数据库中真实存在，但缓存刚失效——所以不是穿透，而是击穿。如果还夹杂大量根本不存在的 ID（如负数、超大随机数），那说明穿透和击穿正在叠加发生。
比对 Key 过期时间与流量高峰的时间窗口
用 redis-cli --scan --pattern "product:*" | xargs -I{} redis-cli ttl {} 抽样检查一批热点 Key 的剩余 TTL。如果发现多个商品 Key 的 TTL 都卡在 0 或刚变为 -2（已过期），且这个时间点恰好和运营预热、整点活动、批量刷新任务执行时刻重合，基本可确认是人为设置的过期时间集中导致。特别注意：不要只看单个 Key，要看“同一业务域下一批 Key 的过期时间是否落在同一秒内”。
抓应用层日志里的重建竞争痕迹
在缓存读取逻辑中加入轻量级埋点：当发现缓存 miss 后，记录是否尝试加锁、是否抢到锁、是否执行了 DB 查询、是否成功回填缓存。击穿发生时，你会看到：大量请求在同一毫秒内都记下“miss → 尝试加锁”，但只有 1 条日志显示“抢到锁 → 查 DB → 回填”，其余几十条都记录“等待锁超时”或“锁被占用，返回旧值/降级”。这种日志分布就是击穿的铁证。
