redis-缓存雪崩

Author Avatar
丁起男 11月 19,2020
  • 在其它设备中阅读本文章

redis-缓存雪崩

数据未加载到缓存中,或者缓存同一时间大面积失效,从而导致所有请求都去查数据库,导致数据库cpu和内存负载过高,甚至宕机。

一个雪崩的简单过程

  1. redis集群大面积故障
  2. 缓存失效,但依然大量请求访问缓存服务redis
  3. redis大量失效后,大量请求转向到mysql数据库
  4. mysql的调用量暴增,很快就扛不住了,甚至直接宕机
  5. 由于大量的应用服务依赖mysql和redis的服务,这个时候很快会演变成各个服务器集群的雪崩,最后网站彻底崩溃

如何预防

缓存的高可用性

缓存层设计成高可用,防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,例如redis sentinel和redis cluster都实现了高可用

缓存降级

可以利用ehcache等本地缓存(暂时支持),但主要还是对源服务访问进行限流、资源隔离(熔断)、降级等。

当访问量剧增,访问出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级,这里会涉及到运维的配合。

降级的最终目的是保证核心服务可用,即使是有损的。

敌人推荐服务中,很多都是个性化的需求,假如个性化需求不能提供服务了,可以降级补充热点数据,不至于前端页面是个空白。

在进行降级之前要对系统进行梳理,比如:哪些业务是核心(必须保证),哪些业务可以允许暂时不提供服务(利用静态页面替换)等,以及配合服务器核心指标,然后设置整体预案,比如:

  • 一般:比如有些服务偶尔因为网络抖动或者服务正在上线而超时,可以自动降级
  • 警告:有些服务在一段时间内成功率有波动,可以自动降级或人工降级,并发送警告
  • 错误:比如可用率低于90%,或者数据库连接池被打爆了,或者访问量突然猛增到系统能承受的最大阈值,此时可以根据情况自动或者人工降级
  • 严重错误:比如因为特殊原因数据错误了,此时需要紧急人工降级

备份和快速预热

  1. redis数据备份和回复
  2. 快速缓存预热

提前演练

建议在项目上线前,演练缓存宕掉后,应用以及后端的负载情况以及可能出现的问题,对高可用提前预演,提前发现问题