缓存击穿是热点key过期瞬间并发请求涌向DB，需用逻辑过期、随机过期时间、分级预热、互斥锁及行为验证来防控。
缓存击穿发生时，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 就会在你最不想它失效的时候，准时消失。
