缓存雪崩问题及处理方案

一、什么是缓存雪崩

    缓存雪崩就是指缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体crash掉了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。

 

下面的就是一个雪崩的简单过程：

1、redis集群彻底崩溃

2、缓存服务大量对redis的请求hang住，占用资源

3、缓存服务大量的请求打到源头服务去查询mysql，直接打死mysql

4、源头服务因为mysql被打死也崩溃，对源服务的请求也hang住，占用资源

5、缓存服务大量的资源全部耗费在访问redis和源服务无果，最后自己被拖死，无法提供服务

6、nginx无法访问缓存服务，redis和源服务，只能基于本地缓存提供服务，但是缓存过期后，没有数据提供

7、网站崩溃

 

雪崩问题在国外叫做：stampeding herd(奔逃的野牛)，指的的cache crash后，流量会像奔逃的野牛一样，打向后端。

 

 

 

导致这种现象可能的原因：

1、例如 “缓存并发”，“缓存穿透”，“缓存颠簸” 等问题，这些问题也可能会被恶意攻击者所利用。

2、例如 某个时间点内，系统预加载的缓存周期性集中失效了。解决方法：可以通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。

 

 

二、预防和解决缓存雪崩问题

1）事前解决方案

• 保证缓存层服务高可用性

和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

部署方式一：双机房部署，一套Redis Cluster，部分机器在一个机房，另一部分机器在另外一个机房。

部署方式二：双机房部署，两套Redis Cluster，两套Redis Cluster之间做一个数据同步。

 

 

2）事中解决方案：

• 对缓存访问进行 资源隔离（熔断）、Fail Silent 降级

避免所有资源hang在访问缓存上，当判断缓存出现问题，则自动进行熔断并按预设进行降级操作。

 

• ehcache本地缓存

应对零散的缓存中数据被清除掉的现象，另外一个主要预防缓存彻底崩溃，ehcache的缓存还能支撑一阵。

 

 

• 对源服务访问进行 限流、资源隔离（熔断）、Stubbed 降级。

无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部 hang 在这个资源上，造成整个系统不可用。

相信大家一定遇到过这样的页面：这些应该就是淘宝的降级策略。

 

降级在高并发系统中是非常正常的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。

 

在实际项目中，我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当复杂的，这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/Netflix/Hystrix)。

 

 

3)事后解决方案

• Redis数据备份和恢复
• 快速缓存预热

 

 

4）提前演练

在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。