缓存击穿是热点key过期瞬间大量请求涌入数据库，确认需满足三要素：key曾存在、已过期、DB有数据，且QPS陡增、SLOWLOG显示GET/SET/DEL密集链路。
怎么确认是缓存击穿而不是穿透或雪崩
缓存击穿有明确的三要素：对应 key 在 Redis 中曾存在、已过期、数据库里有真实数据，且大量请求在失效窗口期集中涌入。如果 redis.get(key) 返回 null，但 db.query(...) 能查到结果，再结合日志里该 key 的访问 QPS 在某一秒内陡增（比如从 200 跳到 8000），基本可锁定为击穿。
注意区分：KEYS * 扫描或 SCAN 不带游标翻页这类误操作会制造假性“高频访问”，实际不是业务热点，而是运维失误；而真正的击穿一定伴随数据库侧对应 SQL 的延迟突增和连接数飙升。
- 检查
INFO stats中的keyspace_misses是否在某个时间点激增，同时instantaneous_ops_per_sec在 Redis 节点上呈现尖峰 - 用
redis-cli --hotkeys查看 TOP 热点，若某 key 排名突然跃升且 TTL 为 -1（刚过期），高度可疑 - 比对应用层埋点：该 key 的缓存未命中率是否在过期前后从 95%
从 SLOWLOG GET 输出里识别击穿相关的慢查询
SLOWLOG GET 返回每条记录含三个关键字段：duration（微秒）、command（命令及参数）、time（时间戳）。击穿场景下，你不会看到单条命令特别慢，而是同一 key 的多条 GET、SET、DEL 在几秒内密集出现，且 duration 普遍不高（比如都在 200–800μs），但频率异常高。
真正要盯的是这些命令的上下文：如果一批 GET hot_item:12345 后紧跟着多个 SET hot_item:12345，且中间夹杂着 DEL hot_item:12345，说明正在重建——这就是击穿的典型链路。此时不要只看耗时，要看“模式”。
- 用
SLOWLOG GET 100分批拉取，避免阻塞；别用SLOWLOG GET不带参数，可能卡住 - 重点关注
command字段中重复出现的 key 名，尤其是带业务标识前缀的（如item:、user:） - 配合
redis-cli --latency排除网络抖动；若延迟稳定在 0.1ms 内，那慢查询就真来自逻辑争抢
为什么 redis-cli --hotkeys 有时不准
redis-cli --hotkeys 基于 LRU clock 和访问计数采样，不是实时精确统计。它默认只扫描部分键空间（约 1/10），且采样周期固定（通常 10 秒），在击穿发生的毫秒级窗口内很可能漏掉峰值。
更可靠的方式是结合 MONITOR 实时抓包（仅限低流量环境），或用 INFO commandstats 查看 cmdstat_get.calls 和 cmdstat_set.calls 的 per-second 增量变化。如果某 key 的 GET 调用量在 1 秒内增长 5 倍以上，而集群其他节点无此现象，基本可断定是单点击穿。
- 生产环境禁用
MONITOR，它会使 Redis 单线程卡死；仅用于临时诊断 -
--hotkeys对小 Key（如 - 集群环境下必须在每个 master 节点单独执行
--hotkeys，不能只查一个节点
击穿发生后，慢查询日志里最该先看哪三行
不用通读全部日志。打开 SLOWLOG GET 50 输出后，优先定位这三类记录：
- 第一条
GET返回null的记录：看它的time是否刚好在 key 过期时刻附近（可用redis-cli INFO keyspace查该 key 的 TTL 剩余值交叉验证） - 紧随其后的
SET记录：确认是否由同一线程或同一服务实例写入，排除多服务并发重建 - 同一秒内第 5 条及以上对该 key 的
GET：如果 duration 逐条升高（比如从 300μs → 1200μs → 2500μs），说明锁等待或 CPU 争抢已开始
击穿的本质不是命令慢，而是“重建过程没被收敛”。日志里看不到错误，只看到一堆看似正常的命令扎堆执行——这才是最难察觉也最该警惕的地方。
