Redis防穿透攻击方法解析

本文深入剖析了Redis防缓存穿透攻击的三大核心实践：必须将布隆过滤器前置到网关或Web中间件层作为第一道安检，杜绝在业务层补救的无效做法；空值缓存需统一存储"NULL"等显式字符串标记并严格控制5–300秒短过期，避免null序列化歧义与内存滥用；参数校验须在入口处强类型、严范围、靠正则硬拦截，弥补布隆无法识别语义非法请求的盲区；同时强调冷启动预热、误判率合理设定（推荐1%）、以及对空值占比和误判率的实时监控告警——三者缺一不可，否则所谓防护只是形同虚设的心理安慰。

布隆过滤器必须前置到请求入口，不能等进到业务层再查

布隆过滤器（BloomFilter）不是“加个缓存”那种可选组件，它是第一道安检门——所有请求在接触 Redis::get 或数据库前就得过它。一旦漏掉这步，恶意 id=-1、sku_id=9999999999 这类非法键会直接涌向后端。

• 典型错误：在 getUserById() 方法里先查 Redis，没命中才去 new 一个 BloomFilter 实例校验——这时请求早已绕过防护，布隆形同虚设
• 正确位置：Web 层中间件（如 Spring Boot 的 HandlerInterceptor）、API 网关、或 Nginx + Lua 模块中完成校验
• 冷启动必须做：上线前用全量合法 user_id 或 product_id 预热 bloomFilter.add()，否则首波请求全被误判为“不存在”
• 误判率别贪低：error_rate=0.01（1%）是较稳选择；设成 0.0001 会导致内存翻倍、初始化变慢，且对防穿透收益极小

空值缓存要带标记、设短过期，且必须区分 null 和 “NULL” 字符串

只写 redis.setex("user:123", 60, null) 是危险的——多数 Redis 客户端序列化 null 为 nil，读出来就是空响应，业务层无法判断这是“真没数据”还是“缓存没生效”。

• 统一用字符串标记：存 "NULL"（全大写）或 "__EMPTY__"，避免类型歧义
• 过期时间严格控制在 5–300 秒：太长（如 1 小时）会让恶意 key 占满内存；太短（如 1 秒）起不到拦截效果
• 读取时显式判断：if ("NULL".equals(userJson)) { return null; }，不能依赖 == null
• 注意客户端差异：Lettuce 默认不存 null，Jedis 可能抛异常，务必在测试环境验证行为

参数校验不能只靠前端或文档，得在网关/Controller 层硬拦

布隆过滤器和空值缓存都防不住格式合法但语义非法的请求，比如 user_id="admin' OR '1'='1" 或 phone="+8613800138000"（号码库根本没这个号）。这类请求连布隆都进不去，或者布隆误判放行，必须靠结构化校验兜底。

• 基础类型强转：接收 Long userId 而非 String userId，非法字符直接 400，不进业务逻辑
• 范围约束：用户 ID 限定在 [1, 2147483647]，商品 SKU 长度固定为 12 位数字，超限直接拒
• 正则兜底：手机号用 ^1[3-9]\\d{9}$，邮箱用标准 RFC 校验，不接受模糊匹配
• 别信 Swagger 注解：@Min(1) 在 Controller 层不生效，必须配 @Valid + BindingResult 或全局 @RestControllerAdvice

监控空值缓存占比和布隆误判率，否则防护等于盲跑

没有监控的防护策略，上线三天就失效。你不知道攻击是否绕过了布隆，也不知道空值是不是快把 Redis 内存撑爆了。

• 关键指标要埋点：cache.null_hit_count（空值命中数）、bloom.miss_false_positive_rate（布隆误判率）、redis.keyspace_hits / keyspace_misses
• 设置告警阈值：空值缓存占全部缓存 key 数 > 15%，或布隆误判率突增 3 倍，立刻触发告警
• 日志留痕：对被布隆拦截的请求记录 query_id 和时间戳，方便溯源攻击源 IP 或 UA
• Redis 内存别只看 used_memory：用 redis-cli --bigkeys 定期扫，确认没大量 "NULL" key 因过期策略失效而堆积

好了，本文到此结束，带大家了解了《Redis防穿透攻击方法解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！