缓存穿透怎么破？空值TTL设置技巧

缓存穿透防护不能只靠简单设置空值TTL，必须将“60s～180s的动态空值过期时间”与业务SLA精准对齐，禁用原始null存储而改用明确标记（如"__NULL__"或结构化响应），同时将空值缓存作为兜底手段，与接口层参数校验、非法ID拦截、轻量限流及定期空key清理深度协同——真正有效的防护不是堆配置，而是让缓存策略成为业务节奏、数据时效与系统健壮性之间精密咬合的齿轮。

空值缓存的TTL不能设成固定 5 分钟

很多人直接抄“TTL=300”，结果在高并发场景下发现缓存里堆满无效空值，内存涨得快、DB 压力没真正降下来。空值 TTL 不是拍脑袋定的，它得和业务查询节奏、数据写入频率、误判容忍度对齐。

• 太短（比如 10s）：攻击者只要每秒发两次相同非法 ID，就又打穿了——刚过期，请求又来，等于白设
• 太长（比如 30min）：新数据刚入库，用户查不到，因为缓存还挂着旧的空值；或者被恶意刷出上万空 key，Redis 内存告警
• 合理区间通常在 60s～180s：覆盖大多数重试/轮询行为，又不至于长期阻塞真实数据生效；若业务有明确“数据写入后多久可查”的 SLA（如“用户注册后 2 分钟内可被搜索”），TTL 应略小于该值

空值内容不能只存 null 或 ""

直接存 redisTemplate.opsForValue().set("user:999999", null, 120, TimeUnit.SECONDS) 会出问题：Spring Data Redis 默认序列化器对 null 处理不一致，有些版本存进去是 nil，取出来变成 "null" 字符串，导致业务逻辑误判为“查到非空数据”。

• 统一用明确标记值，比如 "__NULL__" 或 new byte[0]（空字节数组）
• 读取时必须显式判断：if ("__NULL__".equals(cached)) { return null; }，不能靠 == null
• 如果用 JSON 序列化器，空值建议序列化为 {"code":404,"msg":"not_found"} 这类结构体，避免反序列化失败

空值缓存必须配合接口层校验一起用

只靠空值缓存防穿透，相当于把门锁装在门内侧——外面的人已经进来了。比如攻击者传 id=-1、id=abc、id=9999999999999999999，这些根本不需要查 DB，应该在 Controller 或网关层就拦掉。

• ID 类参数强制校验正整数范围：if (userId 100000000L)
• 字符串类 key 做长度和字符集限制（如只允许数字+字母，长度 ≤ 32）
• 对高频空响应路径（如 /user/{id}）加简单限流：if (rateLimiter.tryAcquire(1, 1, TimeUnit.SECONDS)) { ... }
• 空值缓存只是兜底，不是主力防线

别忘了清理过期空值的副作用

Redis 的 EXPIRE 是惰性删除 + 定期抽样，大量空值 key 过期后不会立刻释放内存。如果某天批量导入新用户，但之前被刷过的空 key 还在，就会造成内存虚高、INFO memory 显示 used_memory 持续偏高。

• 上线前用 redis-cli --scan --pattern "user:*" | head -n 10000 | xargs -I {} redis-cli del {} 清理测试环境残留
• 生产环境定期跑脚本识别长期未更新的空值 key：redis-cli --scan --pattern "user:*" | while read k; do ttl=$(redis-cli ttl "$k"); [[ $ttl -lt 10 ]] && echo "$k"; done
• 更稳妥的做法是：空值 key 加上命名空间前缀，比如 empty:user:999999，方便后续批量操作

空值缓存本身很简单，但真正起效的关键在于它怎么和你的参数校验、监控、运维节奏咬合。TTL 不是配置项，是业务节奏的映射；空值不是占位符，是需要被主动管理的数据实体。

到这里，我们也就讲完了《缓存穿透怎么破？空值TTL设置技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！