Redis如何防止缓存穿透：频率限制防护方法

Redis的缓存穿透防护不能依赖频率限制“单打独斗”，因为它既无法识别语义非法请求（如user_id=-1、order_no="abc"），也难以应对分布式低频攻击；真正有效的方案是将限流作为兜底手段，精准嵌入网关层和DB查询入口，并与布隆过滤器、空值缓存、多维特征校验（格式正则、历史查询热度、布隆校验结果）深度联动，实现从“粗粒度拦截”到“细粒度识别+动态响应”的升级——既避免误伤真实业务空查（如新商品上架），又能在攻击初现时快速定位、限流、告警甚至自动拉黑，让防护更智能、更可靠。

单纯靠频率限制无法识别恶意请求，它只能辅助拦截，且必须配合参数校验、布隆过滤器或空值缓存才能防住缓存穿透。

为什么限流本身不防穿透

缓存穿透的本质是查询“根本不存在的数据”，比如 user_id=-1、sku_id=9999999999、order_no="abc"。这类请求哪怕每秒只发 1 次，只要持续跑，照样打穿 Redis 直击数据库。限流（如每秒最多 5 次）对单个 IP 或用户生效，但攻击者用代理池、肉鸡群发起分布式请求时，每个源 IP 的 QPS 都很低，限流规则完全失效。

更关键的是：redis.get("user:-1") 和 redis.get("user:123") 对 Redis 来说都是合法命令，限流中间件（如 Spring Cloud Gateway 的 RequestRateLimiter）根本不知道这个 key 在业务上是否“语义合法”——它拦不住，也不该拦。

频率限制该放在哪一层、怎么配才有效

限流不是替代方案，而是兜底增强。它只在以下两个位置有意义：

• 网关层（如 Spring Cloud Gateway / Nginx）：对 /api/user/{id} 接口做路径级限流，单位时间窗口内超阈值直接返回 429 Too Many Requests，不进业务逻辑
• Controller 层（加 @RateLimiter 注解或手动调用 RateLimiter.tryAcquire()）：仅用于保护下游 DB 查询逻辑，比如 userService.getUserById(id) 被高频调用时触发熔断，避免 DB 连接池耗尽

注意：RedisTemplate.opsForValue().get(key) 这类缓存读操作不该被限流——它本就该扛高并发；真正要限的是 userRepository.findById(id) 这种 DB 查询入口。

如何让限流和穿透防护联动

单独限流没用，必须和穿透特征绑定。常见可落地的联动方式：

• 监控 redis.miss + db.empty 组合指标：当某接口 1 分钟内缓存未命中率 >95% 且 DB 查询返回空结果超过 100 次，自动触发该用户/IP 的临时限流（比如降为 1qps），并告警
• 在布隆过滤器前置校验失败后（即 bloomFilter.mightContain("user:9999999999") == false），记录该 key 到本地缓存（如 ConcurrentHashMap），对同一非法 key 的后续请求直接拒绝，不走 DB ——这比全局限流更精准
• 空值缓存写入时附带统计：每次执行 redis.setex("user:9999999999", 60, "NULL")，同时用 redis.incr("attack:counter:user") 计数；当该计数 5 分钟内超阈值，自动拉黑该前缀所有请求

容易被忽略的坑：误把“高频正常请求”当攻击

真实业务中存在合理高频查空场景，比如新商品刚上架，大量用户查 sku_id=10000001（尚未入库），此时 db.empty 是真业务空，不是攻击。如果只看空结果数量就限流，会误伤。

所以必须叠加判断条件：

• 该 key 是否通过布隆过滤器？没过 → 高风险
• 该 key 是否符合 ID 格式正则（如 ^\d{1,10}$）？不符合 → 高风险
• 该 key 是否在最近 1 小时内被其他用户查过空？没被查过 → 高风险

三者同时满足，才标记为疑似穿透请求。布隆过滤器冷启动阶段（上线首小时）需关闭此联动，否则全量误判。

终于介绍完啦！小伙伴们，这篇关于《Redis如何防止缓存穿透：频率限制防护方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！