一、概述

缓存穿透:大量请求根本不存在key(下文详解

缓存雪崩redis中大量key集体过期(下文详解

缓存击穿redis一个热点key过期(大量用户访问该热点key,但是热点key过期

穿透解决方案

雪崩解决方案

击穿解决方案

下文进行详解

三者出现的根本原因:Redis命中率下降,请求直接打在DB上

        正常情况下,大量的资源请求都会被redis响应,在redis得不到响应的小部分请求才会去请求DB,这样DB的压力是非常小的,是可以正常工作的(如下图

        如果大量的请求redis上得不到响应,那么就会导致这些请求会直接去访问DB,导致DB的压力瞬间变大而卡死或者宕机。如下图

① 大量的高并发请求打在redis

② 这些请求发现redis上并没有需要请求资源redis命中率降低

③ 因此这些大量的高并发请求转向DB(数据库服务器)请求对应资源

④ DB压力瞬间增大,直接将DB打垮,进而引发一系列“灾害”

 

        那么为什么redis没有需要访问数据呢?通过分析大致可以总结三种情况,也就对应redis的雪崩穿透击穿(下文开始进行详解) 

问题名称 缓存穿透 缓存击穿 缓存雪崩
资源是否存在DB数据库服务器 ×
资源是否存在Redis中 × ×

×

redis没有对应资源的原因 根本不存在该资源(DB也没有 某个热点key过期 部分key集体过期
根本原因

大量的高并发的请求打在Redis上,但是发现Redis中并没有请求的数据redis的命令率降低,所以这些请求就只能直接打在DB(数据库服务器)上,在大量的高并发的请求下就会导致DB直接卡死、宕机


二、情景分析详解

缓存穿透

缓存穿透产生的原因:请求根本不存在的资源(DB本身就不存在,Redis更是不存在)

举例(情景在线):客户端发送大量的不可响应的请求(如下图

        当大量的客户端发出类似于:http://localhost:8080/user/19833?id=-3872 的请求,就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有id=-3872的用户的数据,所以Redis也没有对应数据,那么这些请求在redis就得不到响应,就会直接打在DB上,导致DB压力过大而卡死情景在线或宕机。

        缓存穿透很有可能黑客攻击所为,黑客通过发送大量的高并发的无法响应的请求给服务器,由于请求的资源根本就不存在,DB就很容易被打垮了。

解决方式

        类似于上面的例子,虽然数据库没有id=-3872的用户的数据,但是在redis中对他进行缓存(key=-3872,value=null),这样当请求到达redis的时候就会直接返回一个null的值给客户端,避免了大量无法访问数据直接打在DB上

        对redis进行实时监控,当发现redis中的命中率下降的时候进行原因的排查,配合运维人员访问对象访问数据进行分析查询,从而进行黑名单设置限制服务拒绝黑客攻击)

        使用BitMap作为布隆过滤器,将目前所有可以访问到的资源通过简单映射关系放入到布隆过滤器中哈希计算),当一个请求来临的时候先进行布隆过滤器的判断,如果有那么才进行放行,否则就直接拦截

        类似于用户权限拦截,对于id=-3872这些无效访问就直接拦截,不允许这些请求到达Redis、DB上。

注意事项

  1. 使用空值作为缓存的时候,key设置过期时间不能太长,防止占用太多redis资源
  2. 空值缓存是一种被动的防御方式,当遇到黑客暴力请求很多不存在的数据就需要写入大量的null值到Redis中,可能导致Redis内存占用不足的情况
  3. 使用布隆过滤器,可以在用户访问的时候判断该资源是否存在,不存在则直接拒绝访问
  4. 布隆过滤器是有一定的误差,所以一般需要配合一些接口流量限制(规定用户在一段时间内访问的频率)、权限校验黑名单等来解决缓存穿透的问题

缓存雪崩

缓存雪崩产生的原因:redis中大量的key集体过期

举例:

        当redis中的大量key集体过期,可以理解redis中的大部分数据都被清空了(失效了),那么这时候如果有大量并发的请求来到,那么redis就无法进行有效的响应(命中率急剧下降),请求就都打到DB上了,到时DB直接崩溃

解决方式:

通过使用自动生成随机数使得key的过期时间随机的,防止集体过期
使用nginx缓存+redis缓存+其他缓存,不同层使用不同的缓存,可靠性更强
记录缓存数据是否过期,如果过期会触发通知另外的线程后台去跟新实际的key
  • 使用锁或者队列的方式
如果查不到就加上排它锁,其他请求只能进行等待

缓存击穿

产生缓存雪崩的原因:redis中的某个热点key过期,但是此时有大量的用户访问该过期key

举例:

        类似于“某男明星塌房事件”上了热搜,这时候大量的“粉丝”都在访问该热点事件,但是可能优于某种原因,redis的这个热点key过期了,那么这时候大量高并发对于该key的请求就得不到redis的响应,那么就会将请求直接打在DB服务器上,导致整个DB瘫痪。

解决方案

  • 提前对热点数据进行设置
类似于新闻、某博等软件需要对热点数据进行预先设置在redis中
监控哪些数据是热门数据,实时的调整key的过期时长
只有一个请求可以获取互斥锁,然后到DB中将数据查询返回到Redis,之后所有请求就可以从Redis中得到响应

 


原文地址:https://blog.csdn.net/starboyxyh/article/details/127131427

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_30350.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注