缓存穿透本质是查不到且频繁打穿redis，需在redis前加存在性预判；布隆过滤器应部署于客户端或代理层，仅用于已知热key筛查，并配合异步加载、空值缓存与分级限流机制。
缓存穿透的本质是查不到 + 频繁打穿
Redis 7.0 本身不提供“自动拦截空查询”的能力，GET 命令遇到不存在的 key 就直接回空，后端 DB 被高频击中——这不是 Redis 的 bug，而是设计使然。关键在于：你得在 Redis 前加一道“存在性预判”，而不是等 GET 返回 null 再去查 DB。
布隆过滤器必须放在客户端或代理层，不能塞进 Redis 里跑
Redis 7.0 原生支持 BF.RESERVE、BF.ADD、BF.EXISTS，但布隆过滤器的误判率和扩容策略决定了它不适合动态写入全量业务 key（比如用户 ID 范围太大、新增 key 不可控）。真实场景下更稳妥的做法是：
- 用
redisbloom模块（已集成进 Redis 7.0 默认模块列表），但只用于「已知热 key 集合」的快速筛查，比如活动商品 ID 列表 - 对未知 key（如新注册用户），布隆过滤器会漏判，此时必须 fallback 到异步加载机制，不能直接拒掉请求
-
BF.RESERVE初始化时指定error_rate和capacity很关键：设成0.01和1000000后，实际插入超 120 万 key 就可能误判率飙升，得提前监控BF.INFO输出的size和items
异步加载不能靠单个线程池硬扛，得分级+限流
当布隆过滤器说“可能不存在”，而 DB 查出来确实为空，这时候你要缓存一个空值（SET key "" EX 60），但更关键的是：这个 DB 查询动作不能阻塞主请求线程。常见错误是把 CompletableFuture.supplyAsync() 直接扔进默认 ForkJoinPool，结果大促时线程池被打满，连健康检查都超时。
- 为缓存加载单独配一个有界线程池，核心线程数 ≤ DB 连接池最大连接数，避免雪崩式重试
- 对同一 key 的并发加载请求，用
Caffeine或ConcurrentHashMap做 loading lock（比如computeIfAbsent(key, k -> loadAsync(k))），别让 100 个线程同时查 DB - 空值缓存建议用带前缀的 key，比如
empty:user:123456，并设置比正常缓存更短的 TTL（如 2 分钟），防止长期占内存又没更新机制
Redis 7.0 的 MODULE LIST 和 BF.INFO 是排查布隆状态的第一手依据
线上出问题时，别急着改代码，先确认布隆过滤器本身是否健康。很多团队踩坑是因为没意识到：BF.ADD 失败不会报错，但后续 BF.EXISTS 可能永远返回 0。
- 执行
MODULE LIST确保redisbloom已加载（name 字段含bf） - 用
BF.INFO your_bf_key查看size（实际内存占用）、items（已插入元素数）、filters（是否触发扩容） - 如果
items / size > 8，说明布隆已过载，得重建或拆分 key
布隆过滤器不是银弹，它和异步加载之间那条“信任边界”才是最难调的：信多了，漏查变多；信少了，DB 压力照旧。真正稳定的方案，永远得靠 BF.INFO 数据 + 实时慢查日志 + 空值缓存命中率三者交叉验证。
