缓存雪崩及其解决方案

缓存雪崩是什么，怎么引起的，有什么危害？

缓存雪崩，一般是由大量的key集中在一段时间内失效，或者redis服务故障所引起的,导致查询请求查不到缓存，大量的请求涌入mysql，它会导致mysql瞬间被大量的流量打死，或者是由于该服务接口访问时间过长，导致耗尽了线程资源，不仅会导致该服务其他接口得不到线程资源，也有可能会使上游服务的资源也全都耗在这，然后引起整个系统的崩溃。

预防为主的策略

那么，首先这个肯定是预防为主，我们就应该要尽量避免产生缓存雪崩

1. 对于服务不可访问来说，想要一个高可用的服务，首先我们就要集群使用，即使有redis挂了，依然有其他的redis可以过来提供服务，当然最好就是使用redis cluster集群，多个redis master，不仅有主备服务可以在故障时进行切换，即使真的主备都挂了，那也只是一部分数据不能提供服务了，还有其他的master可以给其他提供服务，尽量的减少redis宕机所带来的影响
2. 对于大量key同时失效来说
   最主要的，就是分散key的失效时间，比如说在插入redis缓存的时候，指定key的失效时间为在一段范围区间内的随机值

降低发生时所造成的危害性

预防只是减少其发生的概率，不代表它就不会发生，如果仍然发生了缓存雪崩的情况，那么我们就应该有一套解决方案，来尽量减少缓存雪崩带来的危害：

1. 防止mysql承受不住瞬间的高流量而宕机
   对于这种情况来说，那就是限制其流量，防止短时间内mysql的流量暴增，简称就是限流，在SpringCloud中，可以使用Hystrix来进行限流，将调用mysql的接口隔离起来，因为Hystrix可以指定调用这个接口所能承受的最大线程数，所以即使有大量的请求过来了，假设设置它的最大线程数为30，而一次数据库操作如果算100ms的话，那么它一秒钟就最多只能处理300的请求数量，这样就达到了限流的目的了。
2. 防止耗尽线程资源，导致该服务甚至整个系统崩溃
   由于缓存雪崩，大量的请求在缓存层获取不到数据，就会去调用查询数据库的接口，而由于数据库操作较慢，如果大量线程都在这里等待着不能及时返回，就很容易把线程资源全都用光，然后上游服务也在等这个服务返回，也直接将线程资源用完，所以现在就能体现出Hystrix的重要性了，它可以设置一个fallback降级服务，当请求数量大于最大线程数+等待数量时，就会直接采用fallback机制快速返回。
   或者是在redis宕机的情况下，还能直接启用熔断，请求一过来就直接fallback返回。
   这里不仅要在mysql上，在其他服务在调用这个服务的时候也都需要用，这样使用资源隔离+熔断+快速返回的机制就能够完美解决这个问题了。

事后的解决方案

如果发生缓存雪崩是因为redis宕机了，这样的话

1. 我们就需要让redis通过备份的RDB文件或者AOF文件迅速恢复重启，尽快提供服务。
2. 或者如果说数据丢失了访问不到了，那么就要进行缓存预热后再提供服务，防止重启后再次发生缓存雪崩。