Redis大促穿透问题解决方案

大促期间，缓存穿透远比高并发更致命——大量恶意或无效请求（如非法ID）会绕过缓存直击数据库，而简单加空值却因TTL设置不当（过长撑爆内存、过短失效）、序列化陷阱、缺乏前置校验或组合防护，反而让防线形同虚设；真正有效的应对不是单点方案，而是“布隆过滤器（热启+合理误判率）+ 短期明确标记的空值（2–5分钟TTL+字符串占位符）+ 参数校验前置 + 白名单兜底 + 实时命中率监控”的四层协同防御，缺一环就可能在流量洪峰中瞬间崩塌。

缓存空值怎么设 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, ...) 就完事，实际运行中常因序列化/反序列化策略崩掉或失效。

• 别直接塞 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%

穿透不是“有没有缓存”的问题，而是“有没有可信的存在性判断”。大促期间最危险的，是以为加了空值就安全了，结果忘了布隆过滤器没热启、监控没开、白名单没配——三者缺一，防线就断在第一环。

今天关于《Redis大促穿透问题解决方案》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！