缓存雪崩是指缓存系统中大规模缓存失效或不可用的情况同时发生，导致大量请求瞬间涌入后端数据库，使得数据库压力激增，甚至导致其崩溃，进而影响整个系统的可用性。缓存雪崩通常由以下几个原因引发：
- 缓存集中过期：如果大量的缓存数据设置了相同的过期时间，在过期时间到达时，这些缓存同时失效。当这些失效的缓存数据被大量并发请求访问时，所有的请求都将穿透缓存直接到达数据库，形成流量高峰，可能导致数据库不堪重负。
- 缓存服务故障：缓存服务器集群因硬件故障、网络问题、软件故障（如Redis主从切换失败、集群脑裂等）或人为误操作等原因整体宕机或大面积不可用，使得所有请求都无法命中缓存，全部转向数据库。
- 缓存预热不足：在系统启动或大范围更新缓存后，新缓存数据尚未完全加载完毕，此时如果有大量请求到来，也会造成大量请求直接访问数据库。
缓存雪崩带来的后果严重，包括：
- 数据库压力骤增：短时间内大量请求直接落到数据库，可能导致数据库CPU、内存、I/O资源耗尽，响应变慢，甚至宕机。
- 系统响应延迟：由于数据库处理能力达到极限，应用程序响应用户请求的时间显著增加，用户体验下降。
- 服务不可用：在极端情况下，数据库崩溃或响应极其缓慢，可能导致整个服务对外不可用。
为防止和应对缓存雪崩，可以采取以下措施：
策略一：分散缓存过期时间
- 设置随机过期时间：为避免大量缓存在同一时刻过期，可以给每个缓存项设置一个随机的过期时间（在期望的有效期内均匀分布），这样可以分散过期时间点，降低同时失效的风险。
- 分批更新：对于定期批量更新的缓存数据，可将其拆分为多个批次，不同批次设置不同的过期时间，避免一次性大面积失效。
策略二：缓存服务高可用设计
- 冗余部署：使用缓存集群或主从复制、哨兵模式等，确保缓存服务的容错性和高可用性。即使部分节点故障，其他节点仍能提供服务。
- 监控与自动故障转移：实施完善的监控系统，及时发现缓存服务异常，并自动进行故障转移或恢复，确保服务连续性。
策略三：数据库保护与限流
- 数据库读写分离：通过读写分离架构，将读请求主要由缓存承载，写请求和少量未命中缓存的读请求才到达主库，减轻主库压力。
- 熔断与降级：在数据库负载过高时，启用熔断机制，暂时拒绝一部分非关键请求，或对服务进行降级处理，如返回缓存中已失效但尚未来得及更新的数据、使用静态备选数据或返回错误提示。
- 请求队列与限流：在数据库前端设置请求队列或使用限流组件，对超出数据库处理能力的请求进行排队、延时处理或直接拒绝，防止数据库被瞬时洪峰压垮。
策略四：缓存预热
- 主动预热：在系统启动或缓存更新后，通过后台任务或脚本预先加载热点数据到缓存中，确保服务启动之初或更新后缓存即有可用数据。
- 懒加载：对于未命中缓存的请求，不要立即去数据库查询，而是先将其放入队列或使用异步任务去加载数据，并返回一个占位符或默认值给客户端。当数据加载完成后，再通过推送或其他方式告知客户端更新。
通过上述策略的综合运用，可以有效地预防和减轻缓存雪崩对系统的影响，保障服务的稳定性和数据的安全性。
