单纯靠频率限制无法防住缓存穿透，因其无法识别语义非法请求（如user_id=-1），且分布式攻击下单IP低频可绕过；限流仅作为兜底，需与布隆过滤器、空值缓存等联动，并结合多维特征精准识别恶意请求。
单纯靠频率限制无法识别恶意请求，它只能辅助拦截，且必须配合参数校验、布隆过滤器或空值缓存才能防住缓存穿透。
为什么限流本身不防穿透
缓存穿透的本质是查询“根本不存在的数据”，比如 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 小时内被其他用户查过空？没被查过 → 高风险
三者同时满足，才标记为疑似穿透请求。布隆过滤器冷启动阶段（上线首小时）需关闭此联动，否则全量误判。
