1. 缓存雪崩：集体失效引发的"多米诺骨牌"

2023年双十一期间，某电商平台曾出现过这样的危机：为减轻数据库压力，技术团队将首页商品、活动规则等关键数据全部缓存至Redis，并统一设置了12小时过期时间。大促前6小时，系统运行平稳，用户流畅浏览商品；但第12小时刚过，所有缓存键同时失效，百万级用户请求如潮水般直接涌向数据库。平时仅需处理1万QPS的数据库，突然面临50万QPS的冲击，瞬间超出承载极限，导致首页无法打开，用户纷纷流失。

这种"大量缓存键在同一时间集中失效，导致请求集中压向数据库"的现象，就是缓存雪崩。其核心诱因是缓存过期时间设置过于集中，常见于大促活动、热点事件等需要批量更新缓存的场景。

2. 缓存击穿：热点数据"突然消失"的连锁反应

2022年某手机品牌新品首发时，技术团队预判到"1元抢购"活动会引发亿级访问，因此将商品库存、价格等核心数据缓存至Redis，并设置1小时过期时间。活动进行到59分钟时，缓存突然失效，原本通过缓存轻松处理的百万级请求瞬间转向数据库。由于数据库未提前优化，无法承受突发压力，导致抢购页面崩溃，用户投诉量激增。

这种"热点数据缓存失效后，大量请求同时穿透缓存直达数据库"的现象，即为缓存击穿。其关键特征是失效的是"单个高频访问的热点数据"，常见于限时秒杀、明星产品推广等场景。

3. 缓存穿透：无效请求"穿透"的系统漏洞

某电商平台曾遭遇恶意攻击：黑客发现系统未对商品ID做有效性校验，于是编写脚本大量请求"ID=-1""ID=9999999"等不存在的商品。由于缓存中没有这些无效数据，请求全部流向数据库。数据库反复查询不存在的记录，CPU使用率飙升至，最终导致服务中断。

这种"请求查询不存在的数据，导致缓存和数据库均无法命中"的现象，称为缓存穿透。其本质是系统对无效请求缺乏过滤，常见于接口未做参数校验、恶意攻击等场景。

应对缓存雪崩的三大方案

• **随机过期时间**：为缓存键设置基础时间（如12小时）+随机偏移（如0.5-2小时），避免集中失效。例如，将"首页商品缓存"的过期时间设为12小时±1小时，分散失效时间点。
• **永不过期+异步更新**：对核心数据（如平台规则、基础配置）设置永不过期，通过定时任务（每小时一次）异步更新缓存，确保数据实时性的同时避免失效问题。
• **多级缓存架构**：采用"本地缓存（JVM）+分布式缓存（Redis）"的双层结构。当Redis缓存失效时，先从本地缓存读取旧数据，同步触发Redis缓存更新，减少数据库压力。

应对缓存击穿的技术组合

• **热点数据永不过期**：针对已知的热点数据（如大促期间的秒杀商品），设置缓存永不过期，通过业务逻辑（如库存售罄时）主动删除缓存，避免因过期导致的击穿问题。
• **互斥锁（分布式锁）**：当缓存未命中时，仅允许一个线程查询数据库并更新缓存，其他线程等待缓存更新完成后再读取。例如使用Redis的SETNX命令实现锁机制，防止大量线程同时访问数据库。
• **服务降级与限流**：在极端情况下（如缓存失效且锁机制未及时生效），对非核心功能（如商品详情页的推荐信息）进行降级，返回默认值或提示语，优先保障核心功能（如支付、下单）的可用性。

应对缓存穿透的防护体系

• **参数校验与拦截**：在接口层对请求参数（如商品ID、用户ID）进行有效性校验，拒绝非法请求（如负数ID、超长字符串）。例如，商品ID必须为正整数且不超过数据库ID值。
• **缓存空值**：当数据库查询结果为空时，将空值（如null或特定标识）缓存至Redis，设置较短的过期时间（如5分钟）。后续相同请求可直接从缓存中获取空值，避免重复查询数据库。
• **布隆过滤器（Bloom Filter）**：对已知存在的键值预先存储在布隆过滤器中。请求到达时，先通过布隆过滤器判断键是否存在：若不存在，直接返回错误；若存在，再查询缓存和数据库。该方案可高效拦截99%以上的无效请求。