缓存雪崩问题及处理方案
Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说缓存雪崩问题及处理方案,希望能够帮助你!!!。
一、什么是缓存雪崩
缓存雪崩就是
指缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体crash掉了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。
指缓存由于某些原因（比如 宕机、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)。
Hystrix(https://github.com/Netflix/Hystrix)。
3)事后解决方案
- Redis数据备份和恢复
- 快速缓存预热
4）提前演练
在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。
今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。
上一篇
已是最后文章
下一篇
已是最新文章
