Redis怎样防范爬虫全量遍历引发的缓存穿透-Redis-PHP中文网

布隆过滤器用于拦截非法ID请求，通过预热合法ID实现存在性快筛，误判率宜设为0.01；需配合带过期时间的显式空值缓存（如"NULL"）和接口层ID格式校验，并监控Redis未命中与空值过期指标。

redis怎样防范爬虫全量遍历引发的缓存穿透

爬虫全量遍历的本质，是构造大量不存在的 user:123456789、order:999999999 这类key发起查询——它们既不在缓存，也不在数据库。布隆过滤器（Bloom Filter）就是干这个的：在请求真正触达缓存/数据库前，先做一次「存在性快筛」。

它不保证100%准确（有极小误判率），但能以极低内存开销挡住99.9%的无效请求。关键在于：误判只可能“说存在但实际上不存在”，绝不会“说不存在但其实存在”——所以它只用于拒绝，不用于放行决策。

初始化时必须预热：从数据库加载所有合法 id（如 SELECT id FROM users），逐个调用 bfAdd 加入过滤器
误判率别设太低（如 0.001）：会导致 bitmap 过大，Redis 内存暴涨；生产常用 0.01（1%），配合百万级容量已足够
别用纯内存布隆（如 Guava BloomFilter）：它无法跨进程共享，多实例部署下会漏判；必须用 RedisBloom 模块或自建 Redis bitmap + 多 hash 位校验

示例逻辑：

if !rb.bfExists('user_filter', user_id):<br>    return {'code': 404, 'msg': '用户不存在'}

布隆过滤器挡不住误判的那1%，也防不了新注册用户尚未入库就被查的场景。这时候需要第二道防线：缓存空结果，但不能简单存 null 或空字符串。

问题在于：如果所有空值都统一用 ""，后续业务层无法判断这是“真没数据”还是“缓存占位符”。更糟的是，若忘记设过期时间，等于永久缓存了“不存在”，导致数据上线后长期查不到。

布隆和空缓存都是“事后防御”，而最省资源的方式，是在第一公里就掐断明显非法请求。比如爬虫常生成负数ID、超长数字、含字母的伪ID，这些根本没必要走缓存链路。

这类校验成本几乎为零，却能过滤掉大量低级遍历流量，还能顺便规避部分越权尝试。

对数字型ID：检查是否 > 0、是否在合理范围（如 user_id ）
对字符串型ID（如 UUID）：用正则粗筛格式，/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i
别只在校验层 throw 异常：返回明确 HTTP 状态码（如 400 Bad Request），方便网关或 WAF 统计拦截率
别和业务逻辑耦合太紧：校验应放在 Controller 或网关层，而非 Service，否则绕过 API 直连缓存时就失效了

布隆+空缓存不是一劳永逸。当某类 key 的缓存未命中率突然飙升，同时 NULL 缓存写入量激增，大概率说明有新一波遍历开始——可能换了策略，或绕过了某层校验。

靠人工看日志太慢，必须把指标接入可观测体系，让数据自己说话。

重点盯两个指标：redis_keyspace_misses（Redis 未命中数）、redis_db_keys_expired（空值 key 过期数），二者同步上涨是强信号
按 key pattern 聚合统计：比如 user:* → NULL 的写入频次，比全局指标更有定位价值
别只看平均值：用分位数（如 P95）看长尾请求，爬虫常集中在某几个 ID 段反复扫
Prometheus + Grafana 是最低成本方案，redis_exporter 开箱即用，无需改业务代码

布隆过滤器的预热时机、空值缓存的 TTL 设置粒度、ID 校验的严格程度——这三者没有标准答案，得看你的数据分布、QPS 峰值和容忍延迟。最容易被忽略的，其实是监控告警的响应闭环：指标异常了，谁来查布隆过滤器是否漏加了新表？谁来确认空缓存是不是该延长 TTL？这些事，代码写不完。