当大量缓存数据同时过期，或者Redis实例突然宕机的时候，就会有大量的请求打到DB，这种场景我们称为缓存雪崩。
雪崩这个词，很形象。想象一下，当缓存都挡不住了，一大堆流量涌向数据库 的场景，像极了当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引，导致向下滑动，引起大量雪体崩塌的场景…
为了应对缓存雪崩，建议系统做如下设计。
1、服务降级
当Redis宕机的时候，让非核心的业务暂时返回空数据或者错误信息，从而避免大量请求直接访问到数据库。
对于核心业务，我们则可以考虑熔断限流。
2、熔断限流
基于现有的业务规划，我们可以做基准测试和容量测试，得到系统在没有缓存的情况下能够支撑的并发数，这个参数可以作为缓存不可用场景下的限流值。
另外，一般在系统出现雪崩的情况，请求响应速度回立刻降下来，通过设置响应的阈值来触发熔断，从而避免系统被源源不断的流量压垮。可以采用Hystrix或者Sentinel等熔断限流组件来实现该需求。
3、搭建可靠集群
如果我们只有一个主节点，那么当主节点宕机之后，缓存服务就再也不可用使用了，从而导致缓存雪崩问题。
如果我们搭建了主从集群，假设主节点宕机了，还可以通过切换主从节点，继续提供缓存服务，而在主从切换期间，可以暂时让服务降级，从而避免了因缓存雪崩导致数据库面临过大压力。
4、尽量避免让key同时过期
如果不是Redis宕机，那么产生缓存雪崩的原因就是大量的key同时过期了，为了避免这种情况发生，建议不要设置大量key在同一时间过期。如果不可以避免，则可以尝试在过期时间添加合理的随机数，让过期时间尽量错开。
