缓存击穿本身不会直接导致内存溢出，它主要压垮数据库；但若兜底逻辑缺陷（如空值缓存未设TTL、fallback反复写入无效key），则可能引发Redis内存泄漏甚至OOM。
缓存击穿本身不会直接导致内存溢出
缓存击穿是热点 key 过期后并发请求穿透到 DB，它主要压垮的是下游数据库，不是 Redis 内存。但如果你的应对逻辑有缺陷——比如用空值或默认对象填充缓存、又没设 TTL，或者 fallback 逻辑反复写入无效 key——那确实会把击穿演变成内存泄漏甚至 OOM。
检查是否因击穿兜底逻辑污染了 Redis
重点排查那些本不该长期存在的 key：空结果缓存、占位符、错误响应体等。这类 key 往往特征明显——数量多、生命周期长、value 很小但总量惊人。
- 用
redis-cli --bigkeys看有没有大量string类型的小 key（比如几十字节但上百万个） - 抽样检查疑似兜底 key：
redis-cli ttl "cache:order:123456"，如果返回-1（永不过期）或远超业务合理范围（如 7 天以上），就是风险信号 - 查 key 命名规律：
redis-cli keys "cache:*:fallback*"或redis-cli keys "*empty*"，确认是否批量生成 - 对比 key 数量和业务 QPS：如果 key 总数每天增长 50 万，而订单查询 QPS 只有 200，基本能断定兜底逻辑失控
验证淘汰策略是否对兜底 key 生效
即使你配置了 allkeys-lru，如果这些兜底 key 是刚写入就立刻被访问（比如每次击穿都查一次 fallback），它们会被频繁 touch，实际很难被淘汰。更糟的是，如果用了 noeviction 或 volatile-* 且没设过期时间，它们就彻底“钉”在内存里了。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
redis-cli config get maxmemory-policy，确认不是noeviction - 对兜底 key 主动加 TTL：
redis-cli expire "cache:user:9999:empty" 300（5 分钟足够缓冲） - 避免在代码里用
SET key value而不用SETEX或EXPIRE—— 这是最常见的漏设 TTL 场景
监控击穿发生时的内存行为变化
单纯看 used_memory 上涨不说明问题，要结合时间点对齐日志。真正的线索藏在突增的 key 数量和低效的淘汰率里。
- 在应用层记录击穿事件（例如捕获
CacheMissException），和 Redis 的INFO memory输出做时间对齐 - 观察
evicted_keys指标是否同步上升：如果击穿期间evicted_keys几乎为 0，说明淘汰策略失效或 key 根本没被选中 - 用
redis-cli --stat持续观察，击穿高峰若伴随keyspace_hits骤降 +keyspace_misses暴涨 +used_memory缓慢爬升，大概率是兜底 key 在堆积
真正危险的从来不是击穿那一刻，而是后续几分钟里，几十万条 "cache:xxx:empty" 被无 TTL 地塞进 Redis —— 它们不占多少单个内存，但合起来能吃掉几 GB。别只盯着热点 key 本身，盯住你写的那行 cache.set(key, emptyObj)。
