什么是缓存预热？为什么需要？怎么做？
简化版
缓存预热是在系统上线、重启或大促前，提前把热点数据加载到缓存里，避免刚开流量时大量请求缓存未命中直接打数据库。常见做法是根据历史访问、运营配置、排行榜、活动商品清单，启动任务批量加载热点 key，并给 TTL 加随机值，避免预热后的 key 同时过期。
详细版
缓存预热解决的是冷启动问题。系统刚发布、Redis 刚扩容、缓存被清空、大促开始前，如果缓存里没有热点数据，第一波请求会集中查数据库，造成数据库抖动。
预热方式包括：
- 启动任务加载基础配置、首页数据、热门商品。
- 定时任务根据访问日志统计 Top N 热点并刷新缓存。
- 运营后台配置活动商品、会场、榜单，发布前预加载。
- Redis 扩容或迁移后，对关键 key 做批量加载。
预热要控制速度，不能为了保护线上请求反而用预热任务把数据库打满；还要给过期时间加随机值，避免预热数据同一时间雪崩。
完整版教学
一、为什么缓存需要预热
缓存不是天然有数据的。第一次访问某个 key 时，如果缓存没有，就要查数据库并回填。平时这没问题，但系统刚启动或活动刚开始时，热点数据可能同时被大量访问，所有请求都发现缓存未命中，就会形成冷启动流量冲击。
预热的目的就是在用户请求到来之前，把大概率会访问的数据先放进缓存，让第一波流量直接命中缓存。
二、哪些数据值得预热
不是所有数据都要预热。应该预热访问集中、可预测、读多写少的数据，比如首页配置、导航分类、热门商品、活动会场、排行榜、系统字典、权限菜单、秒杀商品展示信息。
用户长尾数据、很少访问的数据、变化频繁的数据不适合大规模预热。预热太多会浪费内存，也可能挤掉真正热点。
三、预热数据从哪里来
最常见来源是历史访问日志，统计最近一小时、一天、七天的 Top N key。活动场景可以来自运营配置，比如大促商品池、会场列表。系统基础数据可以来自配置表或字典表。
更成熟的系统会有热点识别任务，持续把热点 key 推送到预热队列，让缓存不是一次性预热，而是动态更新。
四、预热任务怎么控制风险
预热任务本身也会访问数据库。如果一次性加载几十万个 key，数据库同样会被打满。因此预热要限速、分批、错峰执行。可以用队列控制并发，按优先级加载最重要的热点。
预热后的 TTL 也要加随机值。否则所有预热 key 在同一时刻写入、同一 TTL 到期，又会制造一次缓存雪崩。预热和防雪崩必须一起考虑。
五、发布和扩容场景怎么做
应用发布时，可以在新版本接流量前先执行预热，或者让少量灰度流量先把缓存打热。Redis 扩容迁移后，也要关注热点 key 是否迁移完成、是否需要重新加载。
对秒杀这类活动，预热还要配合限流、库存保护、静态化页面。缓存预热只解决读流量冷启动，不解决写热点和库存并发扣减。
六、面试追问与工程边界
面试官常会问“预热是不是越多越好”。不是。预热太多会浪费 Redis 内存，挤掉真正热点，还会让预热任务本身冲击数据库。预热应该按优先级做，先加载确定会被访问的热点，再逐步扩展到次热点。
还要考虑失败兜底。预热失败不能阻塞系统启动太久，否则发布会变脆弱。更好的方式是核心配置强依赖预热结果，普通热点异步预热；预热任务有失败重试和告警，线上读链路仍保留缓存未命中查库逻辑。rnrn工程上还要区分“服务启动预热”和“业务活动预热”。服务启动预热更关注基础字典、配置、权限、首页资源等稳定数据，目标是让系统刚恢复时不抖；业务活动预热更关注秒杀、营销、热点榜单等短期热点，目标是削掉活动开始瞬间的数据库洪峰。前者通常可以做成应用启动后的异步任务，后者更适合做成可观测、可回滚、可重复执行的运维动作，并且要限制并发和速率，避免预热任务本身把数据库打满。面试里能把这些边界说清楚，会显得你不是只背概念，而是真的知道缓存预热在生产环境里怎么落地。
七、常见误区与追问
这道题不能只背概念，要把「缓存预热」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 缓存预热是在流量到来前提前加载热点数据，避免冷启动大量请求打到数据库 | 不要停在名词解释 |
| 流程机制 | 识别热点数据 -> 发布或活动前批量加载 -> 设置合理 TTL 和版本 -> 预热后校验命中率 -> 失败重试和降级 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | 活动开始前把 1 万个商品详情提前写入 Redis，可避免开场前几秒缓存命中率为 0 | 缓存提升吞吐但会引入旧值、热点、内存和失效风暴问题 |
缓存预热 面试拆解：
1. 识别热点数据
2. 发布或活动前批量加载
3. 设置合理 TTL 和版本
4. 预热后校验命中率
5. 失败重试和降级记忆钩子：先说明缓存承担的读写压力，再拆穿透、击穿、雪崩、热点、一致性和淘汰策略；回答时要紧扣「缓存预热」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：预热就是把全量数据塞进缓存。 应只预热热点和关键路径数据，否则浪费内存并拖慢启动。
- 误区：预热成功就永远安全。 数据变更、过期和活动热点变化仍要持续刷新。
- 误区：上线后再靠用户请求回填就够。 高峰冷启动会把数据库打穿。
- 追问：预热数据从哪里来？ 历史访问、运营配置、活动清单、推荐系统和搜索热榜。
- 追问：如何验证预热？ 检查 key 数、命中率、TTL、数据版本和抽样内容。
- 追问：预热失败怎么办？ 限流、降级、分批加载、重试和人工告警。
八、加强记忆
缓存预热是在流量到来前提前加载热点数据，解决冷启动未命中冲击数据库的问题。预热对象要选热点、稳定、可预测的数据；来源可以是访问日志、运营配置、活动清单；执行要限速分批，TTL 要加随机值。预热保护第一波读流量，但不能替代限流、降级和写并发控制。