淘先锋技术网

首页 1 2 3 4 5 6 7

redis穿透

什么是redis穿透?

查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存
这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义
在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。

发生场景:

对于系统A,假设一秒 5000 个请求,结果其中 4000 个请求是黑客发出的恶意攻击。黑客发出的那 4000
个攻击,缓存中查不到,每次你去数据库里查,也查不到。 举个栗子。数据库 id 是从 1 开始的,结果黑客发过来的请求 id
全部都是负数。这样的话,缓存中不会有,请求每次都“视缓存于无物”,直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

解决方案

有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。
另外也有一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

redis雪崩:

什么是redis雪崩?

缓存中大批量热点数据过期后系统涌入大量查询请求
因为大部分数据在Redis层已经失效,请求渗透到数据库层
大批量请求犹如洪水一般涌入,引起数据库压力造成查询堵塞甚至宕机。

发生场景

对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000
个请求,但是缓存机器意外发生了全盘宕机,缓存挂了。

此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了。

此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。

解决方案

事前:redis 高可用,主从+哨兵,redis cluster,避免全盘崩溃
事中:本地 ehcache 缓存 + hystrix 限流&降级,避免 MySQL 被打死。
事后:redis 持久化,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。
用户发送一个请求,系统 A 收到请求后,先查本地 ehcache 缓存,如果没查到再查 redis。如果 ehcache 和 redis 都没有,再查数据库,将数据库中的结果,写入 ehcache 和 redis 中。
限流组件,可以设置每秒的请求,有多少能通过组件,剩余的未通过的请求,怎么办?走降级!可以返回一些默认的值,或者友情提示,或者空白的值。这样可以保证数据库绝对不会死,限流组件确保了每秒只有多少个请求能通过。
只要数据库不死,就是说,对用户来说,2/5 的请求都是可以被处理的。 - 只要有 2/5 的请求可以被处理,就意味着你的系统没死,对用户来说,可能就是点击几次刷不出来页面,但是多点几次,就可以刷出来一次。

redis击穿

什么是redis的击穿

就是说某个 key 非常热点,访问非常频繁,处于集中式高并发访问的情况
当这个 key 在失效的瞬间,大量的请求就击穿了缓存,直接请求数据库,就像是在一道屏障上凿开了一个洞。
击穿和缓存雪崩的区别在于击穿针对某一key缓存,雪崩则是很多key

发生场景

秒杀现场,在同一时间高频访问某一数据,并且当前数据正好过期。

解决方案

可以将热点数据设置为永远不过期
实现互斥锁,等待第一个请求构建完缓存之后,再释放锁,进而其它请求才能通过该 key 访问数据。