缓存穿透本质是无效key频繁击穿至DB，需用BloomFilter在Redis层预检；其误判可控、内存极小，支持高效存在性判断；Redisson中应使用RBloomFilter并正确初始化，注意冷启动、误判率调优及数据一致性问题。
缓存穿透的本质是查不到的 key 频繁打到 DB
用户请求一个根本不存在的 key（比如恶意构造的 user:id:999999999），Redis 里没命中，就直接穿透到数据库。DB 查不到，又不写回缓存，下次还来——流量大了 DB 就扛不住。
关键不是“Redis 没存”，而是“这个 key 永远不该存在”。所以得在 Redis 层就拦住它，而不是等查完 DB 再判断。
BloomFilter 为什么适合做这层拦截
BloomFilter 是一种空间效率极高的概率型数据结构，支持快速判断“某个元素是否可能在集合中”。它有两大特性刚好匹配场景：
- 误判率可控（比如 1%），但不会漏判：如果返回“不存在”，那一定真的不存在；如果返回“可能存在”，才需要继续查 Redis/DB
- 内存占用极小：1000 万个字符串，用 2% 误判率，只要约 12MB 内存
注意：BloomFilter 本身不存原始数据，只存哈希指纹。所以不能用它取值，只能做“存在性预检”。
Java + Redisson 实现 BloomFilter 拦截的关键点
直接用 Redis 原生命令实现 BloomFilter 很麻烦（要自己管位图、哈希函数、扩容）。推荐用 Redisson 的 RPermitExpirableSemaphore 不行——它不支持 BloomFilter。正确选择是 Redisson 的 RBloomFilter。
实操要点：
- 初始化必须指定预期容量
expectedInsertions和误判率errorRate，一旦创建就不能改。例如：rbloomFilter.tryInit(1000000, 0.01) - 所有写入 DB 的合法
key（比如新增用户成功后），必须同步调用rbloomFilter.add("user:id:123") - 读请求流程：先
rbloomFilter.contains(key)→ 返回false就直接返回空，不查 Redis/DB；返回true才走正常缓存逻辑 - 不支持删除操作（标准 BloomFilter 的限制），所以被误删的 key 会一直“假阳性”，但不影响正确性，只略微增加无效查询
示例伪代码：
if (!bloomFilter.contains(key)) {
return null; // 根本不存在，连 Redis 都不查
}
Object value = redis.get(key);
if (value == null) {
value = db.load(key);
if (value != null) {
redis.set(key, value);
bloomFilter.add(key); // 补漏：刚入库的 key 要加进布隆过滤器
}
}
return value;
容易被忽略的三个坑
很多人以为加上 RBloomFilter 就万事大吉，实际线上常翻车：
-
RBloomFilter初始化失败时默认静默，不抛异常。务必检查tryInit()返回值，为false要告警或降级 - 误判率设太高（比如 0.1）会导致大量合法 key 被误判为“不存在”，业务直接 404；设太低（比如 1e-5）会显著增加内存和 CPU 开销，需按量级压测调整
- 冷启动问题：服务刚上线时
BloomFilter是空的，所有请求都走 DB。建议预热脚本把核心 key 批量add进去，或结合本地缓存兜底
最麻烦的是数据一致性：DB 删掉一条记录，BloomFilter 无法删除对应 key，只能靠过期时间或重建整张表——这点必须在业务设计时接受。
