缓存雪崩问题及处理方案
一、什么是缓存雪崩 缓存雪崩就是
指缓存由于某些原因(比如 宕机、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)事前解决方案
- 保证缓存层服务高可用性
2)事中解决方案:
- 对缓存访问进行 资源隔离(熔断)、Fail Silent 降级
- ehcache本地缓存
- 对源服务访问进行 限流、资源隔离(熔断)、Stubbed 降级。
文章图片
降级在高并发系统中是非常正常的:比如推荐服务中,如果个性化推荐服务不可用,可以降级补充热点数据,不至于造成前端页面是开天窗。
在实际项目中,我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离,让每种资源都单独运行在自己的线程池中,即使个别资源出现了问题,对其他服务没有影响。但是线程池如何管理,比如如何关闭资源池,开启资源池,资源池阀值管理,这些做起来还是相当复杂的,这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/Netflix/Hystrix)。
3)事后解决方案
- Redis数据备份和恢复
- 快速缓存预热
4)提前演练 在项目上线前,演练缓存层宕掉后,应用以及后端的负载情况以及可能出现的问题,在此基础上做一些预案设定。
文章图片
推荐阅读
- parallels|parallels desktop 解决网络初始化失败问题
- jhipster|jhipster 升级无效问题
- “精神病患者”的角度问题
- 解决SpringBoot引用别的模块无法注入的问题
- Hive常见问题汇总
- 姚老师互动问答会|姚老师互动问答会 # 问题001(如何更有智慧的和身边人分享金刚智慧())
- 不废话,代码实践带你掌握|不废话,代码实践带你掌握 强缓存、协商缓存!
- 【Hadoop踩雷】Mac下安装Hadoop3以及Java版本问题
- 【教育故事】|【教育故事】 一个“问题学生”的蜕变
- 蓝桥杯试题