缓存空值TTL推荐2–5分钟，用SETEX或set(key, "NULL", 300, TimeUnit.SECONDS)，避免永不过期或24小时；内容用"NULL"等明确标记，前置参数校验更早拦截无效请求。
缓存空值怎么设 TTL 才不翻车
大促期间最怕的不是高并发，而是大量无效请求（比如 productId=999999999、userId=-1）反复打穿 Redis 直奔数据库。缓存空值是最快落地的防线，但 TTL 设错等于白加——设太长，内存被垃圾 key 占满；设太短，起不到拦截效果。
- TTL 推荐 2–5 分钟，用
SETEX或set(key, "NULL", 300, TimeUnit.SECONDS)，别用永不过期或 24 小时 - 空值内容建议用明确标记，如
"NULL"或自定义NullValue对象，避免和真实null混淆导致二次穿透 - 注意：如果业务允许「ID 格式校验」，务必前置做参数校验（比如正则匹配
^\d+$），比缓存空值更早拦住恶意请求
布隆过滤器该不该上、怎么初始化才稳
当商品库有千万级 ID，且无效请求占比超 15%，光靠缓存空值会撑爆 Redis 内存，这时布隆过滤器（BloomFilter）就是刚需。但它不是“一加就灵”，初始化和更新机制出问题，反而让合法请求也被误杀。
- 初始化必须在应用启动后、流量进来前完成，用
dbMapper.getAllKeys()全量加载——别等第一次请求再懒加载 - 误判率别贪低，
0.001（0.1%）是性价比平衡点；设成0.0001会显著增加内存占用，对大促没实际收益 - 不支持删除，所以对频繁上下架的商品，得配合「软下架」逻辑：下架时往布隆过滤器里再加个
"disabled:"+id标记，查询前多一次判断
Java 里用 redisTemplate 写空值时的三个隐藏坑
Spring Boot 项目里看似一行 opsForValue().set(key, null, ...) 就完事，实际运行中常因序列化/反序列化策略崩掉或失效。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 别直接塞
null：RedisTemplate 默认序列化器（JdkSerializationRedisSerializer）对null处理不稳定，容易存成乱码或抛SerializationException - 统一用字符串占位符，比如
"__NULL__"，并在读取时显式判断：if ("__NULL__".equals(value)) return null; - 如果用了
StringRedisTemplate，确保写入和读取都走同一套逻辑——它默认不处理null，set(key, null)会静默失败
大促前必须做的两件事：监控 + 白名单兜底
再好的方案也扛不住定向攻击或突发异常流量。缓存穿透防护不能只靠代码，得有可观测性和快速熔断能力。
- 实时监控
redis.keys("user:id:*")类通配数量 +redis.info("stats").get("keyspace_hits")和keyspace_misses比值，命中率跌破 70% 立即告警 - 对核心接口（如商品详情页）加轻量白名单，用 Redis 的
BITPOS或SET存合法 ID 前缀，请求进来先SISMEMBER legal_product_ids {prefix}，不命中直接 404 - 别指望单点防护万无一失——布隆过滤器可能漏，空值可能过期，白名单可能滞后。真正扛压靠的是组合：布隆过滤器挡 95%，空值兜底 4.9%，白名单+监控守住最后 0.1%
穿透不是“有没有缓存”的问题，而是“有没有可信的存在性判断”。大促期间最危险的，是以为加了空值就安全了，结果忘了布隆过滤器没热启、监控没开、白名单没配——三者缺一，防线就断在第一环。
