需在应用层埋点定位击穿：缓存miss后立即记录结构化日志，关联同一traceId下的DB查询与分布式锁获取日志，通过Loki+Grafana聚合分析时间戳密集度及耗时突变。
怎么从 Redis 日志里定位击穿发生点
Redis 自身不记录“缓存击穿”这类业务语义日志，所谓“击穿日志”其实是你代码中 get 缓存失败后紧接着查 DB 的调用链日志。关键不是翻 Redis 的 slowlog 或 monitor，而是对齐应用层的缓存缺失 + DB 查询双埋点。
- 在
redis.get(key)返回null或空值后，立刻打一条结构化日志，例如：{"event":"cache_miss","key":"product:999999","reason":"db_empty"} - 同一请求上下文中（如用
ThreadLocal或 MDC 透传 traceId），必须同时记录后续的productMapper.selectById()调用耗时和结果 - 避免只记“查不到”，要区分是
DB 返回 null（可能是穿透）还是DB 报错/超时（可能是击穿引发雪崩前兆） - 别依赖 Redis 的
INFO stats中的keyspace_hits/keyspace_misses—— 它无法告诉你哪个 key 在高并发下集中失效
为什么热点 key 失效瞬间很难被日志捕获
击穿的本质是时间窗口极窄：一个 key 过期 → 多个请求几乎同时 get 失败 → 全部涌向 DB。日志里往往只看到一串密集的“miss + DB 查询”，但看不出谁抢到了锁、谁被阻塞、谁重建了缓存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 如果用了分布式锁（如
SET key "1" NX EX 5），要在加锁成功后立即记录{"event":"lock_acquired","key":"product:1001"}，否则所有请求日志长得一模一样 - 没加锁时，DB 查询日志会呈现“毫秒级时间戳完全一致”的集群式爆发，这是最典型的击穿信号
- 注意 JVM 本地时间不同步问题：微服务间日志时间差 >10ms 就可能掩盖真实时序，建议统一接入 OpenTelemetry 打点
Python / Java 里最容易漏掉的击穿埋点位置
开发者常在缓存逻辑外层打日志，却忽略真正决定是否击穿的关键分支——即“缓存为空”之后、“是否尝试重建”的判断点。
- Python 示例中，漏掉对
if not cache_value and not bloom_filter.might_contain(key):的日志，就无法区分是穿透还是击穿 - Java 用
@Cacheable注解时，unless="#result == null"不会触发日志，得在CacheManager的get()方法拦截器里补埋点 - 异步刷新场景（如定时重载热点数据），要在
scheduleRefresh()执行前打日志，否则你以为缓存还热着，其实它已经过期 3 秒了
用 Grafana + Loki 快速筛出击穿模式
单看日志文本效率低，要把 “cache_miss” 和 “db_query” 两个事件在相同 traceId 下做关联聚合，才能确认是否击穿。
- Loki 查询示例：
{job="app"} |= "cache_miss" |~ `key:"product:\d+"` | logfmt | __error__ = "" | line_format "{{.traceId}} {{.key}}" | uniq -c | sort -nr - 在 Grafana 中建 panel，X 轴为时间，Y 轴为
count_over_time({job="app"} |= "cache_miss" |~ `key:"product:1001"`[5m])，峰值突刺就是击穿证据 - 别只盯 QPS 曲线：击穿发生时，DB 的
SELECT耗时 P99 通常跳升 3–10 倍，而缓存层get耗时反而下降（因为全 miss，没走复杂逻辑）
