什么是缓存预热和缓存降级？

简化版

缓存预热指系统上线或重启前，提前把热点数据主动加载进缓存，避免刚启动时缓存是空的（冷缓存）、大量请求一上来全部未命中直接打到数据库（可能瞬间雪崩）。缓存降级指当缓存（或下游）故障或压力过大时，主动放弃部分功能/一致性，返回兜底数据（默认值、旧数据、友好提示），保证系统核心功能可用、不彻底崩溃。一个是「事前把缓存填好」，一个是「事中出问题时保命」。

详细版

缓存预热的做法：

系统启动时，用定时任务/初始化脚本，把预估的热点数据（热门商品、榜单、配置）批量查库并写入缓存。
大促前，提前把活动商品、库存等预热到缓存。
通过历史访问日志分析出热点 key，针对性预热。

缓存降级的做法：

返回默认值/兜底数据：缓存和 DB 都拿不到时，返回一个合理的默认结果或友好提示（“系统繁忙，请稍后重试”）。
返回旧数据/静态数据：用过期的缓存旧值或预先准备的静态兜底页。
关闭非核心功能：如大促时关闭”猜你喜欢""评论”等非核心模块，集中资源保下单主链路。
结合熔断限流：Sentinel/Hystrix 检测到异常时自动触发降级逻辑。

完整版教学

一、缓存预热：别让系统”空着肚子”上线

冷启动问题：系统刚上线或重启时，缓存是空的。此时如果直接放开流量，所有请求都会未命中缓存 → 全部涌向数据库。如果是高并发系统，这一瞬间的冲击可能直接把数据库压垮（相当于人为制造了一次雪崩）。

缓存预热就是解决这个问题：在放开流量之前，先主动把热点数据加载进缓存，让系统”带着热缓存”上线，请求一来就能命中缓存，DB 不会被冷启动冲击。

常见预热方式：

启动时加载：应用启动过程中（如 Spring 的 @PostConstruct、ApplicationRunner），执行初始化逻辑，把已知热点数据查库写入缓存。
定时任务预热：用定时任务周期性刷新/补充热点缓存。
大促预热：电商大促前，运营/系统提前把参与活动的商品、价格、库存等数据预热到缓存，扛住零点洪峰。
基于日志分析：分析历史访问日志，找出高频 key，针对性预热（避免盲目全量预热浪费内存）。

预热要注意别把 DB 压垮——预热本身是大量查库，要控制速率、分批加载。

二、缓存降级：出问题时”弃车保帅”

降级是一种故障应对策略：当系统某部分出问题（缓存挂了、DB 慢了、下游超时）或压力过大扛不住时，主动牺牲一部分东西（非核心功能、数据实时性、一致性），换取核心功能的可用。核心思想是**「宁可提供有损服务，也不彻底不可用」**。

具体到缓存降级，典型手段：

返回兜底默认值：缓存和 DB 都取不到数据时，返回一个预设的合理默认值或友好提示，而不是报错或一直等待。
返回旧数据/静态兜底：宁可返回一份稍旧的缓存数据或预先准备好的静态页面，也不让用户看到错误。
关闭非核心功能：大促高峰时，临时关闭「猜你喜欢」「商品评论」「浏览记录」等非核心模块，把 CPU、DB 连接、缓存资源集中留给「下单、支付」核心链路。
快速失败：对已知会超时的调用，直接快速返回失败/降级结果，不占用线程资源。

三、降级与熔断、限流的配合

降级通常和熔断、限流联动，构成一套完整的服务容错体系（Sentinel、Hystrix、Resilience4j）：

限流：控制入口流量，超过阈值的请求快速失败或排队——防止系统被过量请求压垮。
熔断：监测到某个依赖（如 DB、下游服务）错误率/响应时间超标时，自动「跳闸」，一段时间内不再调用它——防止故障扩散、雪崩。
降级：熔断触发后，执行降级逻辑返回兜底结果——保证用户体验不彻底崩坏。

三者关系：限流是入口控流量，熔断是切断故障依赖，降级是切断后给兜底。

四、预热 vs 降级：一个事前、一个事中

	缓存预热	缓存降级
时机	事前（上线/大促前）	事中（故障/高压时）
目的	避免冷启动冲击 DB	故障时保核心可用
手段	提前加载热点到缓存	返回兜底/关非核心功能
关键词	主动填充、防冷启动	弃车保帅、有损服务

一个是「准备阶段把粮草备足」，一个是「打仗时打不过就断尾求生」。两者都是高可用系统的必备手段。

五、实际案例串联

以电商大促为例，一套完整的缓存高可用策略：

大促前——预热：把活动商品、价格、库存、榜单预热进 Redis 和本地缓存。
过期时间打散：预热的缓存设随机过期，防止集中失效（防雪崩）。
高峰时——限流：网关/应用层限流，削峰。
依赖异常时——熔断：DB 或下游变慢时熔断。
熔断后——降级：返回商品的兜底信息、关闭非核心推荐模块。

预热、打散、限流、熔断、降级层层配合，才能扛住零点洪峰。

六、常见误区与追问

考点	正确口径
缓存预热	系统上线或活动前提前加载热点数据
缓存降级	缓存或后端异常时返回兜底数据或关闭非核心功能
目标	降低冷启动冲击，保护核心链路

before sale:
load top 10000 goods into cache
set staggered TTL

if cache/database pressure high:
return default ranking
hide non-core counters

预热解决“刚开始太冷”，降级解决“扛不住时先保核心”。

误区：预热就是把全量数据塞进缓存。 预热应加载热点和关键数据，全量塞入会浪费内存并拖慢启动。
误区：降级就是系统不可用。 降级是有意牺牲非核心能力，换取核心功能可用。
误区：预热后就不需要限流。 预热只能降低冷启动回源，突发流量仍需要限流、熔断和扩容。
追问：预热数据从哪里来？ 可来自历史访问排行、运营配置、活动商品、搜索热词和离线统计。
追问：降级策略如何设计？ 先区分核心/非核心功能，定义兜底数据、开关、阈值和恢复条件。
追问：如何避免预热造成雪崩？ 批量加载时打散 TTL，控制并发，避免同一时间集中失效。

七、加强记忆

缓存预热 = 事前主动把热点数据加载进缓存（启动时/大促前/基于日志分析），避免冷启动时缓存空、请求全打 DB 造成冲击；预热要控速防压垮 DB。缓存降级 = 事中故障或高压时主动牺牲非核心功能/一致性，返回兜底（默认值、旧数据、关非核心模块、快速失败），核心是「宁可有损服务，不彻底不可用」，常与**限流（控入口）、熔断（切故障依赖）**联动。简明区分：区分：预热是事前填缓存防冷启动，降级是事中弃车保帅保核心。

简化版

详细版