布隆过滤器应在请求入口拦截无效key，需预设容量和误差率、部署于网关层，仅适用于静态可预估集合；空值缓存须用"null"字符串加短ttl（≤5分钟）；acl须限制高危命令，三者协同构成防护防线。
用布隆过滤器在请求入口拦截无效 key
Redis 6.0 原生不带布隆过滤器，但官方模块 RedisBloom 已稳定支持，且与 Redis 6.0+ 完全兼容。它比应用层自己实现更省内存、更少序列化开销，关键是能真正把穿透请求挡在 Redis 外面。
常见错误是把布隆过滤器当“万能字典”用——比如把所有用户 ID 全量加载进去，结果发现注册新用户要实时更新 Bloom Filter，延迟高还容易漏。其实它只适合“静态+可预估”的集合，比如已上线商品 ID、合法手机号号段前缀等。
- 部署方式：用
redis-server --loadmodule /path/to/redisbloom.so启动，或写进redis.conf的loadmodule行 - 初始化：用
BF.RESERVE预设容量和误差率（例如BF.RESERVE user_bf 0.01 1000000），别等第一次BF.ADD再建，否则首次写入会阻塞 - 校验时机：必须放在业务逻辑最外层，比如 Spring Boot 的
@ControllerAdvice或网关层；如果放到 DAO 层再查一次 Redis，就白加了
缓存空值时必须区分“真空”和“未查”
很多人直接 set(key, null)，但 Redis 的 GET 返回 null 既可能是 key 不存在，也可能是存了 null 字符串——这会导致业务逻辑误判。Redis 6.0 没有原生空值语义，得靠约定。
典型踩坑：用 StringRedisTemplate.opsForValue().get(key) 返回 null 就认为“没缓存”，跳过 DB 查询，结果把本该返回 404 的请求直接返回了空对象。
- 推荐写法：空值统一存为字符串
"NULL"（全大写），并设短 TTL，如set(key, "NULL", 2, TimeUnit.MINUTES) - 读取时先判空，再判字符串值：
if (cached != null && "NULL".equals(cached)) { return null; } - TTL 别超过 5 分钟——否则新注册用户可能卡在“空缓存期”里查不到，运营同学会第一时间找你
Redis 6.0 的客户端缓存（Client Side Caching）不能用于防穿透
有人看到 Redis 6.0 新增了 CLIENT TRACKING 就想拿来挡穿透，这是误解。客户端缓存只是把 key-value 副本存在客户端内存里，它不解决“key 根本不存在”的问题，反而会让无效 key 在本地也缓存住，放大穿透风险。
真实场景中，如果你开了 CLIENT TRACKING ON，又没配 REDIRECT 或广播机制，客户端甚至收不到 key 被删除的通知，空值缓存失效都不同步。
- 客户端缓存适用场景：高频读、低变更的热点数据（如配置项、省份列表），且客户端可控（如内部 SDK）
- 穿透防护必须依赖服务端决策：布隆过滤器 or 空值标记，二者都在 Redis 服务端完成判断
- 别把
RESP3协议升级和穿透防护混为一谈——协议升级只影响通信效率，不改变数据存在性逻辑
ACL 权限控制要限制高危命令，防止绕过防护
Redis 6.0 引入 ACL 后，很多团队只给业务账号开 +get、+set，却忘了禁用 KEYS、SCAN、FLUSHDB。攻击者一旦拿到账号，就能扫出所有空值 key，再批量构造请求打穿防护层。
更隐蔽的问题是：运维脚本或监控工具用了默认 default 用户，而这个用户默认拥有全部权限，等于把布隆过滤器和空值缓存全架空了。
- 最小权限原则：业务账号只允许
+get、+set、+pfadd（布隆用）、+bf.exists，禁用所有通配符类命令 - 用
ACL SETUSER显式关闭危险能力：ACL SETUSER app1 -keys -flushdb -debug - 定期 audit：
ACL LIST查权限，ACL WHOAMI查当前连接身份，别让default用户长期在线
