redis 缓存造成穿透怎么办
文章目录
什么是redis 穿透
前面我们有一篇文章介绍了 redis 下的雪崩已经一些解决办法 redis缓存造成雪崩怎么办,点击查看
今天我们再来看下redis下的穿透是什么?
顾名思义:穿透就是把一个容器或者保护罩击穿.
当一个请求过来,我们会根据参数去匹配redis缓存数据;
如果没有找到缓存结果,我们才会接着去请求DB.
那么问题来了:
当成批的并发请求过来,同时去请求一个 redis 缓存中不存在的数据,会发生什么要的效果?
是不是想到了雪崩?
当缓存不能命中,说明我们要去DB上查找数据,而这个并发直接去打DB,真的有点雪崩的意思.
会出现什么要的效果,我们基本想到了.
为什么会有批量并发请求同时访问不存在的数据
作为工程师,我们应该心里有一个准则:
"用户都是恶意的"
如果理解:
在你的代码逻辑中,你不能用正常的善意请求来假设匿名客户端的访问活动;
如果是竞争对手的恶作剧怎么办;
或者黑客的故意DDoS,都有可能.
简单的例子
http://api.domain.com/person/268
假设上面的路由请求是 获取ID为 268 的用户信息.
但是同一时间会有并发访问路由如下:
http://api.domain.com/person/-1
或者
http://api.domain.com/person/2594893459840346434654745683
我们会明显发现这2个ID是不存在的,
数据库中的ID不会出现负数,也不会出现超出最大整形数值,
但是请求过来,我们去redis缓存中无法命中上面ID后,
这些并发请求便会直接打到DB上.
就是不是并发模式请求,陆续长时间的请求这种不存在的数据,对资源浪费严重,对系统健壮性非常有考验.
如果避免redis穿透
直接控制源头;
这种方式有效,但是针对某一个IP,或者固定的几个IP 同时并发访问不存在的资源时,
我们通过运维手段,完全可以禁止这几个IP访问.
但是,当一些黑客软件控制N多的肉鸡来攻击时,上面的方法不可用.
怎么办?
那我们只好把他访问的资源缓存起来,尽量避免它直接打DB.
1.参数做过滤,权鉴,判断
2.当请求路由过来,我们发现redis不存在,然后DB也不存在时,就把此数据缓存到redis中,value 可以是null,空,或者任意你愿意保存的东西......设置一个过期时间,多少分钟或者多少小时.
这样同类的请求过来,直接从缓存中拿到结果返回,就可以抗住redis穿透.