缓存预热应在系统启动后、大促前2小时、配置批量更新后等流量高峰前完成，而非上线后补救；常见错误是用@postconstruct同步阻塞启动，正确做法是启动后异步执行或手动触发，并通过健康检查确认db与redis可用后再执行。

缓存预热该在什么时机触发

预热不是上线后才想起来的事，而是必须卡在流量高峰前完成。系统刚启动、大促前 2 小时、配置中心批量更新后，都是典型触发点。如果等到用户请求进来再加载，就不是预热，是“现烤”，已经算雪崩前奏了。

常见错误是把预热写在 @PostConstruct 方法里，结果服务启动慢、依赖超时、甚至因数据库连接未就绪而失败。更稳妥的做法是：启动后异步执行，或通过独立管理接口手动触发，配合健康检查确认 DB 和 Redis 可用后再跑。

• 全量预热适合数据量小（
• 按需预热更适合商品、用户画像等大数据集，靠访问日志或监控识别 top 100 热 key，只加载这部分
• 定时预热建议放在凌晨低峰期，避免和业务高峰期重叠

预热代码里最容易漏掉的三个细节

预热逻辑看着简单，但生产环境出问题基本都栽在这几个点上：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• redisTemplate.opsForValue().set(key, value, timeout, TimeUnit.SECONDS) 的 timeout 必须设——不设就是永不过期，脏数据会一直滞留；设得太短又失去预热意义，建议比业务平均 TTL 多留 20%
• 预热过程中遇到单条数据加载失败（如 DB 查询超时），不能直接中断整个流程，要 catch 异常 + 打日志 + 继续下一条，否则预热半途而废
• 千万别在预热循环里反复 new RedisConnection 或开事务，容易打满连接池；复用已有 template，批量操作优先用 pipeline

预热后怎么验证是否真正生效

发个 HTTP 请求调完预热接口，不代表数据真进了 Redis。必须验证，否则等于没做。

• 用 redis-cli -h xxx -p 6379 keys "hot_*" 检查 key 是否存在（注意线上禁用 keys *，改用 scan）
• 查 ttl hot_user_123 确认过期时间符合预期，不是 -1（永不过期）或 0（已过期）
• 用 monitor 命令抓几秒流量，看是否有大量 get 请求命中这些 key，而不是穿透到 DB

预热不是一次性动作，它和随机 TTL、互斥锁、降级开关一样，是雪崩防护链条里可测量、可回滚的一环。漏掉验证，就等于埋了个假警报器。