Redis缓存雪崩、击穿、穿透

时间:2021-02-02 22:04:00 来源:互联网 作者: 神秘的大神 字体:

目录
  • 一、缓存三大问题
  • 二、缓存雪崩
    • 2.1 雪崩场景
    • 2.1 应对方案
  • 三、缓存击穿
    • 3.1 击穿场景
    • 3.2 应对方案
  • 四、缓存穿透
    • 4.1 穿透场景
    • 4.2 应对方案

一、缓存三大问题

这三个问题一旦发生,就会导致大量请求进入后台的数据库,如果有大量并发同时到达数据库,有可能会导致数据库宕机,影响业务,也有可能会导致一系列连锁反映,很可能导致业务长时间无法恢复。

接下来本文详细介绍这三个问题的发生场景以及对应的解决方案。

二、缓存雪崩

2.1 雪崩场景

雪崩是指大量请求无法在redis进行处理,原本预期在redis的中存在的数据却在redis中不存在,紧接着这些请求被全部转发到了数据库,导致暑数据库压力大增。产生雪崩的原因主要有两个:

  1. 缓存中有大量的数据同时过期,导致大量请求无法在redis中无法处理。
  2. Redis宕机

2.1 应对方案

针对缓存中有大量的数据同时过期的应对方案

  1. 避免给大量业务数据设置相同的过期时间,业务场景中总会出现同时实效的case,比如基于订单的下单时间。对于这种场景,可以在过期时间后面加个随机的时间比如(1-3分钟)。这样既保证了业务基本在相近的时间过期,也不会在同时间集中过期。
  2. 降级,如果雪崩已经产生,可以对业务进行降级,非核心数据直接返回指定的静态数据(缓存中没有也不去数据库请求),只有核心数据持续访问缓存(如果缓存没有,也可以去访问数据库,由于限制了非核心数据的请求,这个时候db的压力应该不大)。

针对Redis宕机应对方
redis宕机就等于所有数据同时失效,等于最强雪崩,redis所能承载的qps是万级别,而单个数据库所能承载的qps是千级别,这个时候如果所有请求全部进入DB,必然会导致DB的奔溃。有两个处理方法。

  1. 服务彻底熔断,当前进来后直接返回,不再访问数据库,对服务使用方来说,整个服务是不可用的,对业务的影响最大,但是彻底保护了数据库。

  2. 请求限流,在业务系统的请求入口控制每秒进入服务的次数,限流的比例可以基于之前的数据进行分析,比如在雪崩前入口的qps是10000,其中9000被redis承载,1000进入了数据库(说明数据库能承载1000的qps),那么这个时候可以将入口的qps 限制为1000,这样既保证了数据库的安全,也不至于业务不可用(部分可用状态)。限流示意图如下。

  3. 主从集群部署,实现redis的高可用,当主节点宕机后从节点可以切换为主节点继续提供服务。

当然宕机后的一系列处理方法同样适用于大量key同事过期的case。

三、缓存击穿

3.1 击穿场景

热点数据在redis中找不到,和雪崩相比,击穿对应的热点数据数据量比较小,但是这些数据的请求量非常高,导致大量请求都被大到了数据库。
击穿发生在热点数据失效时。

3.2 应对方案

对于缓存击穿解决方案比较简单,对于热点数据可以设置永不过期,这样就解决了失效问题。

四、缓存穿透

4.1 穿透场景

缓存穿透是指查询的数据既不在缓存也不在数据库,请求redis时候发现缓存缺失,再去访问数据库,发现数据库也没有,所以无法补全缓存数据,导致每次查询都会去请求数据库,当有
大量类似的请求场景时候,也会对数据库造成巨大的压力。
发生穿透的场景:

  1. 业务误操作导致本应该存在的数据被误删除
  2. 恶意攻击,专门查询数据库中没有的数据,利用穿透的漏洞。
  3. 设计问题,代码不严谨,已知可能为空的数据没有去做判断。

4.2 应对方案

有三个方法可以解决穿透问题。

  1. 给缓存赋空值或者缺省值,一旦发现没有业务数据,可以赋为空置或者留一个标示值,比如有值的时候对应的值是一个list,如果发现没有业务数据可以付一个空的list,这样等下次再来访问时,发现redis已经有缺省值,可以直接返回,避免了多次访问数据库。
  2. 通过业务规则判断,如果通过某些规则就可以知道没有数据,则可以直接不用访问。
  3. 使用布隆过滤器,可以快速判断数据是否存在,避免从数据库中查询是否存在,减轻数据库的压力。原理和相关使用后期专门写一篇文章介绍。

本文完。