什么是缓存预热？为什么需要？怎么做？
简化版
缓存预热是在系统上线、重启或大促前，提前把热点数据加载到缓存里，避免刚开流量时大量请求缓存未命中直接打数据库。常见做法是根据历史访问、运营配置、排行榜、活动商品清单，启动任务批量加载热点 key，并给 TTL 加随机值，避免预热后的 key 同时过期。
详细版
缓存预热解决的是冷启动问题。系统刚发布、Redis 刚扩容、缓存被清空、大促开始前，如果缓存里没有热点数据，第一波请求会集中查数据库，造成数据库抖动。
预热方式包括：
- 启动任务加载基础配置、首页数据、热门商品。
- 定时任务根据访问日志统计 Top N 热点并刷新缓存。
- 运营后台配置活动商品、会场、榜单，发布前预加载。
- Redis 扩容或迁移后，对关键 key 做批量加载。
预热要控制速度，不能为了保护线上请求反而用预热任务把数据库打满；还要给过期时间加随机值，避免预热数据同一时间雪崩。
完整版教学
一、为什么缓存需要预热
缓存不是天然有数据的。第一次访问某个 key 时，如果缓存没有，就要查数据库并回填。平时这没问题，但系统刚启动或活动刚开始时，热点数据可能同时被大量访问，所有请求都发现缓存未命中，就会形成冷启动流量冲击。
预热的目的就是在用户请求到来之前，把大概率会访问的数据先放进缓存，让第一波流量直接命中缓存。
二、哪些数据值得预热
不是所有数据都要预热。应该预热访问集中、可预测、读多写少的数据，比如首页配置、导航分类、热门商品、活动会场、排行榜、系统字典、权限菜单、秒杀商品展示信息。
用户长尾数据、很少访问的数据、变化频繁的数据不适合大规模预热。预热太多会浪费内存，也可能挤掉真正热点。
三、预热数据从哪里来
最常见来源是历史访问日志，统计最近一小时、一天、七天的 Top N key。活动场景可以来自运营配置，比如大促商品池、会场列表。系统基础数据可以来自配置表或字典表。
更成熟的系统会有热点识别任务，持续把热点 key 推送到预热队列，让缓存不是一次性预热，而是动态更新。
四、预热任务怎么控制风险
预热任务本身也会访问数据库。如果一次性加载几十万个 key，数据库同样会被打满。因此预热要限速、分批、错峰执行。可以用队列控制并发，按优先级加载最重要的热点。
预热后的 TTL 也要加随机值。否则所有预热 key 在同一时刻写入、同一 TTL 到期，又会制造一次缓存雪崩。预热和防雪崩必须一起考虑。
热点清单 -> 全局限速读取权威源 -> 带版本写入 -> 覆盖率/TTL/内存校验
-> 未达门槛不放量；达标后按 1% -> 5% -> 20% 灰度接流量五、发布和扩容场景怎么做
应用发布时，可以在新版本接流量前先执行预热，或者让少量灰度流量先把缓存打热。Redis 扩容迁移后，也要关注热点 key 是否迁移完成、是否需要重新加载。
对秒杀这类活动，预热还要配合限流、库存保护、静态化页面。缓存预热只解决读流量冷启动，不解决写热点和库存并发扣减。
六、面试追问与工程边界
面试官常会问“预热是不是越多越好”。不是。预热太多会浪费 Redis 内存，挤掉真正热点，还会让预热任务本身冲击数据库。预热应该按优先级做，先加载确定会被访问的热点，再逐步扩展到次热点。
还要考虑失败兜底。预热失败不能无限阻塞系统启动，否则发布会变脆弱。启动必需配置应有明确的失败策略，普通热点则可异步预热；任务需要重试、告警和限速，线上读链路仍保留受控回源逻辑。
工程上还要区分“服务启动预热”和“业务活动预热”。前者关注基础字典、权限、首页资源等稳定数据；后者关注秒杀、营销、榜单等短期热点。活动预热应做成可观测、可重复执行的运维动作，并设置并发、速率和数据库负载门禁。
七、怎样估算速度并验收结果
预热速度由数据库余量决定，而不是由 Redis 写入速度决定。假设要加载 120 万个 Key，数据库可安全提供的额外查询预算为 4000 QPS，理论最短读取时间是 1200000/4000=300 秒；考虑序列化、重试和写缓存，应再留余量。若有 20 个实例并行执行，每个实例不能各跑 4000 QPS，而应共享全局预算。
写入前要记录数据版本或生成时间，避免预热任务读到旧副本后覆盖线上新值。可写入版本化 namespace，完成数量、抽样内容、版本、TTL 和内存校验后再原子切换入口；失败时保留旧 namespace 回滚。直接覆盖同一批 Key 虽简单，却难以判断半成功状态。
验收不能只看任务显示“成功”，至少检查预期 Key 覆盖率、value 版本、TTL 分布、缓存命中率、数据库 QPS、Redis 内存和淘汰量。预热后 evicted_keys 快速增长，说明数据集超过容量或挤掉了原有热点，此时继续加载反而降低命中率。
预热完成的标准是目标流量能够在数据库预算内安全接入，而不是任务把清单遍历了一遍。
八、热点清单也可能选错
历史 Top N 只能代表过去，无法覆盖尚未开始的活动热点。预热清单应组合历史访问、运营活动、搜索趋势和关键路径；每个来源标注优先级、预计 QPS、value 大小和失效时间，容量不足时先保证高价值 Key。
| 来源 | 优点 | 主要偏差 |
|---|---|---|
| 历史访问 Top N | 自动、贴近真实流量 | 看不到新活动与突发热点 |
| 运营活动清单 | 能预测即将到来的流量 | 人工漏配或配置过期 |
| 搜索/推荐趋势 | 能较早发现升温内容 | 热度可能快速变化 |
| 核心路径固定清单 | 稳定、容易校验 | 容易长期膨胀 |
还要估算内存，而不是只数 Key。10 万个平均 20,000B 的商品对象约需 1.86GiB 原始 value 空间，实际还包含键名、对象元数据和碎片；若容量水位不足，应减少对象字段或清单规模，而不是让淘汰策略边预热边删除。
九、任务如何做到可重入和可停止
预热任务应幂等、可断点续跑，并记录清单版本、游标、成功/失败数和限速配置。任务重启后从已确认游标继续，单 Key 失败进入有上限的重试队列；取消活动时能够停止尚未执行的批次，避免继续加载无用数据。
版本 namespace 切换后，旧 namespace 不应立刻全量 DEL。先保留一段回滚窗口，再通过 UNLINK 或分批过期清理；否则清理本身可能阻塞 Redis，且切换异常时没有可回退数据。若新旧结构双写，还要在结束前做数量与抽样内容对账。
十、常见误区与追问
- 误区：预热就是把全量数据塞进缓存。 应只预热热点和关键路径数据，否则浪费内存并拖慢启动。
- 误区：预热成功就永远安全。 数据变更、过期和活动热点变化仍要持续刷新。
- 误区：上线后再靠用户请求回填就够。 高峰冷启动会把数据库打穿。
- 追问：预热数据从哪里来？ 历史访问、运营配置、活动清单、推荐系统和搜索热榜。
- 追问：如何验证预热？ 检查 key 数、命中率、TTL、数据版本和抽样内容。
- 追问：预热失败怎么办？ 限流、降级、分批加载、重试和人工告警。
十一、加强记忆
缓存预热是在流量到来前提前加载热点数据，解决冷启动未命中冲击数据库的问题。预热对象要选热点、稳定、可预测的数据；来源可以是访问日志、运营配置、活动清单；执行要限速分批，TTL 要加随机值。预热保护第一波读流量，但不能替代限流、降级和写并发控制。