Redis缓存击穿应对与热点预热技巧

本文深入剖析了Redis缓存击穿这一高发性能瓶颈的本质——并非数据缺失，而是热点key在过期瞬间遭遇海量并发请求直击数据库的“时间窗口危机”，并系统性地给出了从预防（逻辑过期、随机TTL、精准分级预热）、执行（异步+限流+可观测的Spring Boot预热实践）、防御（业务层互斥锁设计、降级兜底）到验证（行为级而非存在性验证）的全链路解决方案，强调缓存治理不是单点优化，而是预热、淘汰、加锁与监控紧密咬合的闭环工程，直击线上最棘手的“刚预热完就击穿”痛点。

缓存击穿发生时，Redis里key没了但DB里还有

缓存击穿不是数据不存在，而是“刚过期的热点key被并发猛攻”——比如首页商品详情、秒杀库存这些高频访问项，在 EXPIRE 到期那一毫秒，几十上百请求同时发现 Redis 没值，全涌向数据库。这不是设计缺陷，是时间窗口和流量叠加的真实压力。

所以不能只靠“加锁”，得从源头减少这个窗口出现的概率：

• 永不过期不现实？那就用“逻辑过期”：把真实数据 + 过期时间戳一起存进 String 或 Hash，应用层自己判断是否该刷新，Redis 层保持长期存活
• 避免所有 key 集中在整点失效：初始化时对 expire 时间加随机偏移，比如基础 3600 秒，再 +(int)(Math.random() * 600)
• 别让预热变成“启动时全量 dump”：预热只加载真正会被首屏/首页/登录后立即触发的 key，例如 home:banner:list、user:config:default，而不是整个用户表

Spring Boot 启动时手动预热的正确姿势

很多人在 @PostConstruct 里写个 for 循环塞 Redis，结果服务卡住、超时、甚至 OOM。根本问题在于：没区分“必须同步完成”和“可异步兜底”的数据。

实操建议：

• 核心数据（如配置开关、地区字典）走同步预热，在 ApplicationRunner 中执行，失败直接抛异常中断启动
• 非关键但量大的数据（如商品类目树、热搜词榜）改用 @Async + 延迟执行，启动后 3 秒再跑，避免阻塞主线程
• 预热过程必须带限流：用 RedisTemplate.opsForValue().set() 时，批量用 pipeline，单次不超过 500 条；避免一次发几万 key 把 Redis 写满或打挂连接池
• 加日志埋点：每批预热前后打 log.info("preload {} keys, cost {}ms", size, elapsed)，否则出问题连哪批挂了都找不到

预热代码里最容易漏掉的互斥锁陷阱

你以为预热完就万事大吉？错。预热只是“第一次准备”，而缓存击穿常发生在“预热之后、下一次刷新之前”的空档期。这时候如果多个实例同时重启，或某个节点缓存被清空，又会回到“多线程争抢重建”的老路。

所以预热逻辑本身要自带防御：

• 不要只依赖“启动时一次性加载”，要在业务查询方法里保留 tryLock("lock:hotkey:user:123") 的 fallback 路径
• 锁的 key 必须带业务标识，比如 lock:product:detail:10086，不能共用一个全局锁，否则所有商品详情串行化
• 锁超时时间必须严格小于业务查询总耗时，建议设为 DB 查询耗时 × 2 + 200ms，防止死锁又不至于太短导致频繁抢锁失败
• 加锁失败后别直接 return null，应降级为本地缓存（Caffeine）或默认值，否则前端看到的就是空白页

验证预热是否真生效：别只看 Redis CLI

redis-cli KEYS * 是最危险的验证方式——线上禁用，且看不出 key 是否真被业务代码读到。真正有效的验证是观测行为而非存在。

推荐三步确认法：

• 查 Redis 监控面板里的 instantaneous_ops_per_second 曲线：服务刚启动那分钟，应该有明显 write spike，之后趋于平稳
• 用 redis-cli --scan --pattern "home:*" 看 key 数量是否符合预期，注意别用 KEYS 命令
• 最关键的：调用一次接口，抓包或日志里确认它走了 redisTemplate.opsForValue().get() 而不是 jdbcTemplate.query() ——很多预热写了，但业务代码没走缓存分支，等于白干

预热不是写完就结束的动作，它必须和缓存淘汰策略、锁机制、监控告警串成一条链。漏掉任意一环，热点 key 就会在你最不想它失效的时候，准时消失。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis缓存击穿应对与热点预热技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。