Redis缓存穿透解决方案详解

本文深入剖析了Redis缓存穿透这一高发性能风险，系统讲解了“业务层校验—布隆过滤器—缓存空值”三层递进式防御体系：从零成本的参数合法性前置拦截，到以极小内存开销拦截99%无效请求的布隆过滤器（强调预估容量、全局单例与写库同步更新），再到兜底的缓存空值策略（严控过期时间、禁用null值、区分语义空响应），并直击各方案落地痛点——如空值内存膨胀、布隆误判与不可删除、校验遗漏等实战陷阱，为开发者提供可立即落地、兼顾性能与健壮性的完整解决方案。

缓存空值：最简单但最容易爆内存

缓存穿透发生时，攻击者或异常流量用大量随机 id（比如负数、超大整数、字符串乱码）反复查数据库，Redis 没命中，DB 也查不到，结果每次都要穿透到底层。缓存空值就是把这种“查无此物”的结果也塞进 Redis，下次再碰同样 key 就直接返回，不打 DB。

但关键不是“存”，而是怎么存：

• 空值不能设长过期时间——redisTemplate.opsForValue().set(key, "", 5, TimeUnit.MINUTES) 是合理选择；设成 1 小时或永不过期，等于给恶意 key 养了长期户口
• 别用 null 做缓存值——Java 里 redisTemplate 存 null 会报错或静默失败；Go 的 rdb.Set 存空字符串 "" 更稳妥
• 空值要和业务正常空响应区分开——比如用户不存在返回 "NULL" 字符串，而接口成功但数据为空则返回 {} 或 {"code":0,"data":null}，避免下游误判

这招见效快，但若业务本身存在大量合法但稀疏的 ID（比如注册用户 ID 跳号严重），空缓存会快速吃光 Redis 内存，监控 used_memory 和 keys *:xxx 数量必须跟上。

布隆过滤器：拦截 99% 无效请求的刚需组件

缓存空值是“事后补漏”，布隆过滤器（Bloom Filter）是“事前筛人”。它不存真实数据，只用几个 bit + 多次哈希标记“哪些 key 是可能存在的”。只要布隆说“不存在”，那就一定不存在，请求直接拦在网关或 service 层，根本不会走到 Redis 查一步。

实操要点很具体：

• 初始化参数得按真实数据量预估：bloom.NewWithEstimates(10000000, 0.01) 表示支撑 1000 万用户、允许 1% 误判率；设小了误判飙升，设大了浪费内存（但其实 1.8MB 就能扛 1 亿 key）
• 必须在写 DB 的同时更新布隆——新增用户后，立刻 userBloom.Add(userID)；删用户？布隆不支持删除，只能重建或加二级缓存兜底
• 别在每次请求里 new 一个布隆过滤器——它是全局单例，加载到内存后常驻；否则 CPU 和 GC 压力会反噬性能

注意：布隆只是概率结构，有极小可能把存在的 key 判为“不存在”（漏放），所以它永远只能做第一道闸门，后面仍需保留缓存空值作为保底。

业务层校验：被低估却最省事的第一道防线

很多缓存穿透压根不用动 Redis 或布隆——ID 是 Long 类型，请求却传 "abc"；用户查询接口要求 userID > 0，却来了 -1 或 0；这些连缓存都不该碰。

真正在代码里加几行判断，成本几乎为零：

• Spring Boot 里用 @Min(1) 注解校验入参，配合 @Valid 统一拦截
• Go HTTP handler 开头就写 if userID
• 网关层（如 Spring Cloud Gateway）配正则路由规则，直接 400 拒绝非数字 path 变量

这类校验不依赖任何中间件，不增加 RT，还能顺便挡住爬虫和脚本攻击。但它只管“明显非法”，对“看起来合法但 DB 真没有”的 key（比如刚注册还没同步到缓存的用户）无能为力——所以它必须和布隆/空值组合使用。

空值缓存 + 布隆 + 校验：三者不是选一个，而是叠着用

线上出过问题的团队基本都踩过这个坑：上线布隆后发现漏放变多，赶紧加空值缓存；结果某天批量导入数据忘了刷布隆，大量新用户首次访问全走空值路径，Redis 内存暴涨。

真正稳的链路是线性兜底：

• 先过业务校验 → 挡掉格式错误
• 再查布隆 → 挡掉 99% 的无效 key
• 布隆说“可能存在”，才查 Redis → 命中直接返回
• Redis 未命中，查 DB → 查到就写缓存；查不到就写短过期空值

布隆负责“大面过滤”，空值负责“最后托底”，校验负责“防低级错误”。少任何一环，都会在流量突增或数据不一致时露出破绽。

本篇关于《Redis缓存穿透解决方案详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！