空值缓存过期时间设太长会导致Redis内存耗尽。因空值key不被访问，LRU无法淘汰，且每个约占100–200字节，数量多时迅速撑满内存；安全TTL应为1–5秒，需匹配业务数据可见延迟，并配合布隆过滤器、前缀命名、LFU策略及监控告警综合防控。
空值缓存的过期时间设太长，是 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 应该设多少才安全
没有通用值，但有硬约束逻辑：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须短于业务可接受的“新数据延迟可见时间”——比如用户注册后 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 挖坑。
