空值缓存与布隆过滤器必须协同使用：空值缓存需设2～5分钟TTL、带前缀、存空字符串；布隆过滤器须落地Redis、预热并同步更新；查询前先BF.EXISTS，再加锁防击穿。
直接说结论：空值缓存 + 布隆过滤器双保险，缺一不可。只做空值缓存，内存和性能压力大；只用布隆过滤器，误判率导致漏拦。
空值缓存必须设 TTL，且不能超过 5 分钟
空值缓存不是“永久记住不存在”，而是给恶意或错误请求一个冷却窗口。不设 TTL 或设太长（比如 24 小时），会导致 Redis 内存被大量无效 null key 占满，尤其在 ID 范围宽泛的场景（如订单号、用户手机号）下极易 OOM。
-
CACHE_NULL_TTL推荐设为2～5分钟，用TimeUnit.MINUTES - key 必须带前缀，例如
"cache:null:shop:"，方便后期用redis-cli --scan --pattern "cache:null:*"清理 - 写入空值时，值建议用空字符串
""而非null，避免某些客户端序列化异常 - 注意：Spring Cache 的
@Cacheable默认不缓存null返回值，得配合unless = "#result == null"或自定义CacheResolver
布隆过滤器要预热，且不能只靠 Guava BloomFilter
Guava 的 BloomFilter 是单机内存结构，重启即丢，无法用于分布式服务。线上真实场景中，必须把布隆过滤器落地到 Redis 或专用服务（如 RedisBloom 模块）。
- 初始化时，从数据库全量扫描有效 ID（如所有已上架商品 ID），哈希后批量写入 Redis 的
BF.ADD命令 - 新增/下架数据时，同步调用
BF.ADD或BF.MADD，保证过滤器与业务状态一致 - 查询前先执行
BF.EXISTS cache:bloom:shop {id}，返回0则直接拦截，不查缓存也不查 DB - 误差率
fpp不建议低于0.01，否则内存占用翻倍但收益有限；expectedInsertions应按未来 3 个月增量预估，而非当前总量
queryWithPassThrough 函数里容易漏掉并发竞争
空值缓存本身不解决高并发下多个线程同时发现缓存 miss、同时查 DB 的问题——这其实是缓存击穿的变种。所以 queryWithPassThrough 逻辑必须包裹互斥锁。
- 推荐用 Redis 的
SET key value NX EX seconds实现原子加锁，key 建议为"lock:shop:" + id - 锁超时时间必须短于业务查询耗时（如 DB 查询平均 200ms，则锁设
300ms），防止死锁 - 获取锁失败后，应退避重试（如
Thread.sleep(10)最多 3 次），而不是立即查 DB - 特别注意：空值写入和正常数据写入，都应在锁内完成，否则仍可能重复穿透
真正难的不是写对一行 stringRedisTemplate.opsForValue().set(...)，而是让布隆过滤器跟得上数据变更节奏、让空值 TTL 和锁超时在压测中不互相打架、让监控能一眼看出是漏过了布隆还是绕过了空值缓存——这些细节没埋点、没日志、没压测，上线就踩坑。
