冷缓存为什么要预热
缓存被清空、实例被切换或新集群上线后缓存是全冷的：所有请求都要回源，数据库或后端服务的压力瞬间放大，恢复时间取决于后端能顶住多少回源流量。预热方案要提前准备——整理热点键清单、按来源回放数据、渐进放量——并监控命中率恢复曲线，确认回源压力确实降下来了。
基本信息
| 输入材料 | 热点键清单与数据来源 |
|---|---|
| 常见方式 | 数据回放、按比例渐进放量 |
| 观测指标 | 命中率恢复曲线与回源请求量 |
| TTL 约定 | 预热数据同样要带 TTL，避免旧数据长期驻留 |
| 主要风险 | 无预热直接全量放量，回源把后端打崩 |
典型使用场景
- 新集群上线：先灌热点数据再切流量，避免首次访问全部回源
- 缓存清空后恢复：按热点清单分批复灌，边灌边观察
- 大促前准备：提前把核心商品与配置类数据预热到位
- 发布后验证：看命中率曲线是否在预期时间内回到常态
- 容量评估：用回源比例评估后端能否承受未命中流量
预热与观测
预热与观测
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses' # 计算命中率
redis-cli DBSIZE # 预热进度
redis-cli INFO clients | grep connected_clients # 回源侧连接压力
redis-cli TTL hot:key:1001 # 确认预热数据带 TTL
redis-cli INFO commandstats | grep set # 回灌写入量预热方式对照
| 方式 | 适用情况 | 注意点 |
|---|---|---|
| 按清单回放 | 热点集合明确 | 清单要定期更新，避免过期 |
| 按比例渐进放量 | 热点不明确 | 放量节奏要看后端水位 |
| 离线数据导入 | 数据本身可离线产出 | 导入期间留意实例延迟与 CPU |
| 被动回填 | 无法提前预知访问 | 要评估后端能否承受首轮回源 |
预热脚本与业务发布解耦：放进同一个发布流程会互相拖慢，预热失败还会连带阻塞业务上线。
预热数据不带 TTL 会让旧值长期驻留，后续数据更新后仍可能读到过期内容；回填时统一设置与业务一致的过期时间。