缓存预热怎么做
冷缓存意味着第一波流量几乎全部回源，数据库很容易被打穿。上线、重启或扩容新节点加入后，应按热点清单提前写入缓存，同时控制写入速率、给键设置带抖动的过期时间，避免大量键在同一时刻集中过期造成第二轮回源。
基本信息
| 适用 | 上线、重启、扩容、缓存清空后的任何场景 |
|---|---|
| 预热内容 | 热点数据与核心业务链路依赖的数据 |
| 速率控制 | 按数据库承受能力限速，分批完成 |
| 效果验证 | keyspace_hits 上升、回源查询量下降 |
预热脚本思路
预热脚本思路
# 1) 从访问日志或埋点排行导出热点键清单
# 2) 批量写入并设置带抖动的 TTL，避免同时过期
for key in $(cat hot_keys.txt); do
value=$(loader --key "$key") # 从数据源加载真实值
redis-cli SET "cache:$key" "$value" EX $((600 + RANDOM % 120)) # TTL 抖动，错开过期时间
sleep 0.01 # 限速，控制对数据库的压力
done
# 3) 预热完成后核对命中率
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'
redis-cli DBSIZE预热检查点
| 阶段 | 动作 | 判据 |
|---|---|---|
| 清单准备 | 从日志或埋点生成热点键 | 覆盖核心链路，不用人工拍脑袋 |
| 速率控制 | 限制每秒写入数量 | 数据库指标平稳，无慢查询突增 |
| TTL 设置 | 基准值加随机抖动 | 避免同一时刻集中过期 |
| 效果验证 | 查看命中率与回源量 | 命中率回升、回源 QPS 下降 |
| 异常兜底 | 保留限流与降级开关 | 预热影响业务时可立即暂停 |
典型使用场景
- 大促或活动上线前预热核心商品与配置数据
- 实例重启后恢复热点，避免重启即高峰
- 集群扩容新节点加入后预热，防止新节点冷启动
- 缓存清理后的补救：按点击数重新填充热点
- 灰度发布验证：先预热再放量，降低首波回源压力
预热清单要能持续维护：从访问日志或埋点排行自动生成，人工维护的清单很快就会与真实热点脱节。
不要预热全量数据：耗时长、占满内存，且大部分键根本不会被访问，只预热点即可。