布隆过滤器必须前置到请求入口层，如网关或反向代理层，不可置于DAO或Service层；空值缓存TTL不宜超5分钟，推荐60–300秒；空值不写本地缓存；需监控redis miss、db query、empty cache三指标联动验证效果。
布隆过滤器该放在哪一层做拦截
布隆过滤器必须前置到请求入口层，不能依赖业务服务去调用。否则在高并发下，多个请求同时发现缓存未命中、又同时查布隆过滤器，就失去了“一次判断、全局生效”的意义。典型错误是把 bloomFilter.mightContain(key) 放在 DAO 层或 Service 层里——这会导致重复计算、误判率叠加、且无法拦截已知非法 key。
推荐位置：网关层（如 Spring Cloud Gateway / Kong / Nginx + Lua）或反向代理层。这里能对所有请求统一做预检，且不侵入业务逻辑。
- 若用 Java 网关，可加载
ScalableBloomFilter到内存，并通过定时任务从数据库同步有效 key（注意加锁防重复加载） - 若用 Nginx，可用
lua-resty-bloomfilter模块，但需注意共享字典大小限制和 key 序列化方式 - 务必避免把布隆过滤器实例放在无状态 Pod 里——每次重启丢失，等价于失效
空值缓存的 TTL 设置为什么不能超过 5 分钟
空值缓存本质是用时间换空间，TTL 过长会放大两个风险：一是恶意构造大量随机 key 导致 Redis 内存快速耗尽；二是真实数据上线后，因空值未过期而持续返回错误结果（比如新用户注册后立即查询，却拿到缓存中的空值）。
实践中，setex(key, 300, "") 是较稳妥的起点。再结合业务容忍度微调：
- 用户类数据：建议 60–180 秒（注册/审核流程短，空值可快速刷新）
- 商品类数据：可放宽至 300 秒（上架周期长，短时误判影响小）
- 绝对禁止使用永不过期的
set(key, "")，哪怕加了后台清理逻辑也不可靠
多级缓存下空值要不要写入本地缓存
不要。本地缓存（如 Caffeine）写入空值会带来严重一致性问题：一旦某个节点缓存了 user:999999 的空值，而其他节点还没写入，后续请求打到不同节点就会出现“有的返回 null、有的查库成功”的现象。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
空值只应写入共享缓存（Redis），并确保所有服务实例访问的是同一套 key 空间。本地缓存只用于加速「已确认存在」的数据读取：
- 查 Redis 命中 → 写入本地缓存（带 TTL，且不超过 Redis 的 TTL）
- 查 Redis 未命中但布隆过滤器放行 → 查库 → 成功则双写（Redis + 本地），失败则仅写 Redis 空值
- 布隆过滤器拒绝或参数校验失败 → 不触达任何缓存层
如何验证拦截策略是否真正生效
最直接的方式不是看日志，而是监控三组指标的联动变化：redis_keyspace_hits / redis_keyspace_misses、db_query_count（WHERE id = ? 类型）、以及应用层记录的 empty_result_from_cache 计数。
当穿透被有效拦截时，你会看到：
-
redis_keyspace_misses上升（因为布隆过滤器放行了更多请求去查 Redis），但db_query_count明显下降 -
empty_result_from_cache计数稳定上升，且集中在高频无效 key 上（如user:1234567890这类明显非连续 ID） - 数据库慢查询日志中，
SELECT ... WHERE id = ?的执行频次与缓存 miss 频次不再强相关
漏掉的关键点是：布隆过滤器的 error_rate 必须在预热阶段就压测校准。线上设为 0.001 看似安全，但如果有效 key 总量超千万，实际误判量可能达上万 —— 这些误判请求仍会穿透到 DB，只是分散了压力而已。
