什么是缓存雪崩？
Redis缓存，一般是加在database前一层，因此一般的请求处理过程是这样的：
请求进入web后端服务器 -> web后端服务器请求redis，查看是否命中缓存，如果命中，则直接返回 -> 如果缓存没有，则继续查询database -> 查到数据后，更新到缓存，同时返回给请求端。
因此，如果发上以下两种情况，就是缓存雪崩（cache avalanch）：
1. 线上服务运行时，redis服务挂掉；
2. 线上服务运行时，大批量的缓存数据同时失效，大量请求直接请求到database；
3. 线上服务刚上线，应用系统新上线的时候，此时 redis 集群中是没有数据的，这个时候如果有大量的请求过来的，那么这些请求都会直接访问数据库。
如何解决缓存雪崩问题？
1. 对于上面的第二个场景，缓存失效时间设置的时候增加个随机值，使过期时间不再相同；
2. 对于上面的第一个场景，事故发生前肯定要尽量保证redis的高可用，即最好就不让redis挂掉，这就设计到redis的高可用(主从模式，哨兵模式，集群模式)；
事故发生中：要使服务非常健壮，即通过熔断机制进行兜底(兜底进入逻辑即检测到redis服务挂掉)，比如Ehcache + hystrix形势，这样是为了保证不让过多的请求打到database层(保证其他服务的可用性)，否则这么多的qps打到database，一旦数据库挂掉，不仅影响当前接口，使用相同database的其他接口服务也受牵连。
事故发生后：redis基于持久化的数据快速重建数据，将数据恢复加载到内存。
3. 对于上面的第三个场景，或者是redis挂掉，并且持久化数据不可用时。
这种情况称为冷启动，冷启动会容易导致服务起不来，解决方案就是缓存预热。那么如何预热数据？可以例行分析高频流量访问数据，将此部分高频数据从database查出来，写入redis。