缓存穿透本质是无效请求未被拦截，导致redis和数据库均无数据时反复直击db；典型表现为命中率骤降、慢查询含非法id；防御需在网关或controller层限流+参数校验，空值缓存仅作兜底，布隆过滤器或白名单才是主防线。
缓存穿透不是Redis本身的问题，而是业务请求绕过缓存直接打到数据库的后果——只要请求的key在Redis和数据库里都不存在，且没做拦截，就会反复穿透。
缓存穿透的本质是“无效请求没被拦住”
它不依赖Redis配置或版本，只取决于你是否放任非法key一路走到DB。典型表现是：监控看到Redis命中率骤降、MySQL慢查询日志里全是SELECT ... WHERE id = -1或超大随机ID这类明显异常的语句。
- 攻击者用脚本批量请求
user_id=9999999999这种超出业务范围的ID - 前端没校验，用户手动输入
sku=abc提交请求 - 爬虫按ID递增遍历，但中间有大量逻辑删除或未发布的记录
这些请求不会触发缓存回填，因为DB查不到结果，所以每次都是“Redis miss → DB miss → 空响应”，形成死循环。
接口限流必须在缓存之前做，否则没意义
把限流放在redisTemplate.opsForValue().get()之后就晚了——穿透请求已经绕过缓存，限流只拦住了部分，剩下的照样打DB。真正有效的限流要卡在最外层，比如Spring Boot的@ControllerAdvice或网关层。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 用
Redis + Lua实现原子计数：例如INCR加EXPIRE组合，限制/product/{id}接口每分钟最多100次请求 - 对可疑
key单独限流：比如id为负数或长度超过20位的请求，直接走独立限流桶，阈值设得更严（如10次/分钟） - 避免全局限流误伤正常流量：不要用
rateLimiter.tryAcquire()对整个服务统一限，而是按接口路径+参数特征维度区分
示例片段（Spring Boot）：
String key = "limit:product:" + userId + ":" + Math.abs(id % 100); Long count = redisTemplate.execute(limitScript, Collections.singletonList(key), "60", "100");
这里limitScript是预加载的Lua脚本，保证INCR和EXPIRE原子执行；id % 100做分桶，防止单个恶意id打爆整个桶。
空值缓存只是补救，不是防御
很多人以为给空结果设set("product:-1", "NULL", 60, TimeUnit.SECONDS)就能解决问题，其实这只对**重复请求同一非法key** 有效。一旦攻击者换一批新key（比如-1,-2,-3…），空值缓存完全失效，还白白占用内存。
- 空值缓存适合兜底，比如用户偶尔输错一次ID，别让ta再刷一次就打崩DB
- 但它无法应对批量构造
key的场景，此时布隆过滤器或参数白名单才是主防线 - 注意清理策略：不要长期保留空值，5~60秒足够，过长会拖慢LRU淘汰
真正容易被忽略的是——限流规则和空值缓存都依赖key的提取逻辑是否一致。如果限流用path + query拼接，而空值缓存只存id，攻击者改个timestamp参数就能绕过限流，却仍命中空值缓存，反而让Redis缓存大量无用键。
