Redis缓存穿透怎么解决？设置空值过期时间

Redis空值缓存虽能有效缓解缓存穿透，但过长的过期时间（如30分钟）极易引发内存雪崩——因空值key不被频繁访问，LRU策略无法淘汰，数万条空值即可迅速耗尽内存并触发OOM；实践中安全TTL应严格控制在1–5秒内，需与业务数据可见延迟对齐，并必须配合布隆过滤器前置拦截、key前缀规范、LFU淘汰策略升级及实时监控告警等多层防护，否则看似简单的“set null”操作，实则是在数据库和Redis之间埋下双重隐患。

空值缓存的过期时间设太长，是 Redis 内存耗尽的直接推手之一。 不是“可能”，而是线上真出过：某次把 NULL 的 TTL 设成 30 分钟，攻击脚本一跑，几万随机 id 塞进 Redis，内存半小时涨满，OOM command not allowed when used memory > 'maxmemory' 开始刷屏。

为什么空值缓存会吃光内存

空值本身不占多少空间，但数量级失控后就是灾难：

• 每个空值 key 占用 Redis 内部结构（dictEntry + sds）约 100–200 字节，10 万个 key 就是 10–20 MB —— 这还不算 key 名长度和哈希表扩容开销
• Redis 默认使用 allkeys-lru 淘汰策略时，空值 key 因为“从不被访问”（查一次就返回 null，后续请求也命中），根本不会被 LRU 触发淘汰
• 如果用了 volatile-lru，而你又没给空值 key 设置过期时间（或设得太长），它们就彻底变成“钉子户”

空值 TTL 应该设多少才安全

没有通用值，但有硬约束逻辑：

• 必须短于业务可接受的“新数据延迟可见时间”——比如用户注册后 2 秒内要能查到，那空值 TTL 就不能超过 2 秒
• 推荐范围：1–5 秒。实测中 redisTemplate.opsForValue().set(key, "NULL", 2, TimeUnit.SECONDS) 能扛住每秒几百次恶意 ID 查询，且内存增长可控
• 绝对不要复用正常数据的 TTL（如 30 分钟），这是踩坑最频繁的操作
• 如果业务允许，可以按 key 类型分级：用户 ID 类设 2 秒，订单号类设 5 秒，配置项类干脆不缓存空值

怎么防止空值 key 疯狂堆积

单靠调 TTL 不够，得加拦截层：

• 在布隆过滤器之后再做空值缓存：先过 BloomFilter.mightContain(id)，只对“可能存在”的 id 才走 Redis → DB 流程，大幅减少空值写入量
• 对 key 命名加前缀并限制长度：cache_null:user: 而不是裸 ID，方便后期用 SCAN cache_null:user:* COUNT 1000 批量清理
• 开启 Redis 的 maxmemory-policy 为 allkeys-lfu：LFU 至少能淘汰那些“写入后几乎不被再访问”的空值 key，比 LRU 更适合这个场景
• 加监控告警：用 INFO memory 中的 used_memory_human 和 mem_allocator 配合 DBSIZE，当空值 key 占比超 30% 时触发告警

空值缓存不是开关，是精度控制阀。TTL 设短了，抗不住重复查询；设长了，内存就成筛子。真正难的不是写那行 set(key, "NULL", 2, SECONDS)，而是想清楚：这个“2 秒”，到底是保护数据库，还是在给 Redis 挖坑。

本篇关于《Redis缓存穿透怎么解决？设置空值过期时间》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！