缓存雪崩问题及其解决方案

什么是缓存雪崩

描述：
缓存雪崩一般是指，缓存层（例如redis集群）出现了异常，不能正常工作了。于是所有的请求都会达到存储层（数据库层），存储层的QPS会暴增，出现大量请求压垮存储层的情况。

当然如果缓存设置了过期时间，导致大量数据同时过期，进而大量请求打入数据库中，引起数据库压力过大甚至宕机。对于这种情况我们可以将缓存数据的过期时间设置随机或者设置缓存永不过期。

然后实际上可能redis集群出现了崩溃，导致缓存不可用，那么此时可能会导致以下问题：

1. 缓存服务大量对redis的请求被hang住，占用资源
2. 缓存服务大量的请求打到源头服务去查询数据库，直接打死数据库
3. 源头服务因为数据库被打死也崩溃，对源服务的请求也hang住，占用资源
4. 缓存服务大量的资源全部耗费在访问redis和源服务无果，最后自己被拖死，无法提供服务
5. nginx无法访问缓存服务，redis和源服务，只能基于本地缓存提供服务，但是缓存过期后，没有数据提供。
   这就类似雪崩的效应，导致整个系统崩溃，这是非常可怕的。。。。会带来巨大的经济损失。
   

解决方案

事前

redis高可用

redis本身的高可用性，复制，主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上

双机房部署，一套redis cluster，部分机器在一个机房，另一部分机器在另外一个机房

还有一种部署方式，两套redis cluster，两套redis cluster之间做一个数据的同步，redis集群是可以搭建成树状的结构的

事中

ehcache本地缓存

ehcache的缓存，应对零散的redis中数据被清除掉的现象，另外一个主要是预防redis彻底崩溃
多台机器上部署的缓存服务实例的内存中，还有一套ehcache的缓存

限流降级，资源隔离，降级

这个解决方案的思想是，在缓存失效后，通过如hystrix来进行资源隔离限流熔断，控制对某个服务请求的线程数量。

此方案可以保证用户还是能访问到部分的数据，不至于系统崩溃。
当然最好的方案是尽量不要让缓存集群死掉，做好高可用方案。

事后

redis数据备份和恢复，重新启动

快速缓存预热，redis重新启动起来。