Redis 中的缓存雪崩、穿透、预热、降级、更新分别是什么意思

核心定义：大量缓存 key 在同一时间集中过期失效，或缓存服务（如 Redis 集群）直接宕机，导致所有请求瞬间穿透到数据库，引发数据库压力骤增甚至宕机。

核心原因 ：
- 缓存 key 过期时间设置过于集中（如批量设置 1 小时过期）。
- Redis 集群故障（如主从切换失败、节点宕机）。
可能影响：数据库雪崩（无法承载高并发而宕机），进而导致整个业务系统不可用。
解决方案 ：
- 过期时间"打散"：给每个 key 的过期时间加随机值（如 1小时±10分钟），避免集中过期。
- 缓存集群高可用：部署 Redis 主从+哨兵/Redis Cluster，避免单点故障。
- 降级兜底：缓存失效时，返回默认值（如"服务繁忙"），不直接查数据库。
- 持久化保障：开启 RDB/AOF 持久化，缓存宕机后可快速恢复数据。

核心定义：请求查询的是"不存在的数据"（如查询 ID=-1 的用户），这类数据既不在缓存中，也不在数据库中，导致每次请求都穿透缓存直接打向数据库，长期积累会压垮数据库。

核心原因 ：
- 业务逻辑漏洞（如用户 ID 本应是正数，却传入负数）。
- 恶意攻击（如批量构造不存在的 key 发起请求，消耗数据库资源）。
可能影响：数据库长期处理无效请求，CPU/IO 占用过高，无法响应正常业务。
解决方案 ：
- 布隆过滤器（Bloom Filter）：提前将数据库中所有"有效 key"存入布隆过滤器，请求先过过滤器，不存在的 key 直接拦截（误判率极低）。
- 缓存"空值"：若查询结果为 null，仍将该 key 与空值（如 ""）存入缓存（设置短过期时间，如 5 分钟），避免重复穿透。
- 接口层校验：对请求参数做合法性校验（如 ID 必须为正数），直接拦截无效请求。

核心定义 ：系统启动前或业务高峰来临前，主动将 热点数据（如电商大促的"爆款商品"、首页高频访问数据）提前加载到缓存中，避免"冷启动"时缓存为空、请求全打数据库。

核心原因 ：
- 系统重启后缓存为空，首次请求需查数据库并回写缓存，若并发高，数据库会瞬时承压。
- 业务高峰（如秒杀、直播带货）前，未提前加载热点数据，高峰时缓存"miss"率极高。
解决方案 ：
- 脚本预热：写批量脚本（如 Python/Shell），从数据库查询热点数据，批量写入 Redis。
- 分批次加载：按业务优先级分批次加载数据（如先加载首页数据，再加载分类页数据），避免一次性加载压垮 Redis。
- 服务启动触发：系统启动后，自动调用预热接口，加载预设的热点 key 列表。

核心定义 ：当系统面临高并发（如秒杀）或缓存服务故障（如 Redis 响应超时）时，主动牺牲非核心缓存功能，优先保障核心业务（如支付、下单）的可用性，避免整个系统崩溃。

核心原因 ：
- 缓存服务超时/宕机，若继续等待缓存响应，会导致请求阻塞。
- 高并发下，缓存+数据库仍无法承载，需削减非核心请求的资源消耗。
降级策略 ：
- 熔断降级：缓存响应超时（如超过 500ms），直接触发熔断，返回默认值（如"商品暂时无法查看"）。
- 限流降级：限制非核心接口的缓存访问（如仅允许 10% 的请求查缓存），剩余请求返回兜底数据。
- 关闭非核心缓存：如大促时，关闭"商品浏览历史"等非核心缓存，释放资源给"商品详情""下单"等核心缓存。

核心定义 ：保证缓存中的数据与数据库中的数据一致的策略，避免缓存数据过期/脏读（如数据库数据已改，缓存仍存旧数据）。

核心更新策略 （3 种常用方案）：

策略名称	核心逻辑	优点	缺点
Cache-Aside	1. 读：先查缓存，miss 则查库，回写缓存； 2. 写：先更数据库，再删缓存（而非改缓存）。	实现简单，适用大部分场景	可能有"缓存删除后、新数据回写前"的短暂 miss。
Write-Through	1. 写：先更数据库，再同步更新缓存； 2. 读：直接查缓存（缓存与库强一致）。	数据强一致，读性能高	写性能低（需同时更库和缓存），适用写少读多场景。
Write-Behind	1. 写：先更缓存，缓存异步批量更新数据库； 2. 读：直接查缓存。	写性能极高	数据可能不一致（缓存更新后，数据库未同步），适用非核心数据（如用户浏览量）。