空对象缓存无法应对高频恶意扫描，因每个随机key都会真实写入redis导致内存与cpu迅速耗尽；不区分“真不存在”与“暂未创建”，新增数据被旧空值覆盖；且缺乏布隆过滤器预加载和协同校验时拦截失效。
空对象缓存能拦住大部分穿透请求，但无法应对高频恶意扫描、数据新增延迟、或缓存与布隆过滤器协同缺失的场景。
空值缓存为什么挡不住持续扫描？
当攻击者用脚本每秒生成 10 万个随机 user:id:999999999 这类根本不存在的 key 时，setex("user:id:999999999", 300, "NULL") 会真实写入 Redis —— 每个 key 占用内存、消耗连接、触发过期淘汰逻辑。即使单个空值只存 5 分钟，10 万 QPS × 300 秒 = 3000 万个 key，Redis 内存和 CPU 很快被拖垮。
- 空值本身不区分“真不存在”和“暂未创建”，所有非法 key 都被平等地接纳并缓存
- Redis 的
EXPIRE是惰性 + 定期删除，大量短 TTL 空值堆积会导致过期键扫描压力上升 - 业务上新增了 ID=999999999 的用户，但缓存里还挂着 4 分 59 秒前的
"NULL"，导致新用户查不到
布隆过滤器必须配合预加载才有效
很多人直接在代码里 new 一个 BloomFilter 就开始 mightContain()，结果发现拦截率极低——因为没加载合法 key 列表。布隆过滤器不是魔法，它依赖初始化时把所有可能存在的 key（比如全量用户 ID、商品 ID）哈希进去。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 初始化必须在服务启动时完成，例如从数据库
SELECT id FROM user或读取离线导出的 ID 文件 - 增量更新难：用户注册后，需同步调用
bloomFilter.put(newId)，否则新用户请求会被误判为“不存在” - 误判率要按量级设：1000 万用户，
error_rate=0.01需约 14MB 内存；设成 0.001 就要翻倍，得权衡内存和漏放率
空值 + 布隆过滤器 + 本地缓存三层组合才稳
单纯靠 Redis 层做空值或布隆，高并发下仍有单点压力。真实生产环境需要分层防御：
- 第一层：Nginx 或网关层用
lua_shared_dict缓存最近 1000 个被标记为“无效”的 key（TTL 60 秒），快速拦截重复扫描 - 第二层：布隆过滤器判断“该 key 是否可能存在于数据库”，否决掉 99% 的非法请求，不进 Redis
- 第三层：Redis 中仍保留空值缓存，但只对通过布隆校验、却查库失败的 key 写入，且 TTL 缩短到 60–120 秒
这三层加起来，既避免 Redis 被空值打爆，又防止布隆漏判导致数据库裸奔，还覆盖了布隆不可达的冷启动/增量场景。
真正容易被忽略的是布隆过滤器的生命周期管理——它不能只在应用进程内初始化一次就完事；用户批量导入、ID 号段跳变、分库分表后 key 构造规则变化，都会让布隆失效。没有定期重载或双写机制，再好的空值策略也撑不过一次运营活动。
