服务器高可用!

Redis缓存使用流程

客户端向服务器发送读请求,此时后台会先去缓存中查数据,如果数据命中,那么返回结果,反之去数据库中查询,如果数据库中查到数据,那么返回数据,并且写入缓存,如果没有查到该数据即返回空结果

Redis缓存使用流程

缓存穿透(数据未命中)

概念

缓存穿透的概念很简单,用户想要查询一个数据,发现Redis缓存中没有,也就是缓存没有命中,于是就向数据库查询,然后发现也没有,于是本次查询失败。当用户很多的时候(秒杀场景),如果在缓存都没有命中,于是都去请求了数据库DB,一瞬间就给数据库造成巨大的压力,这种情况就是常说的缓存穿透。

解决方案(这里简单介绍、具体过程后面学习了更新)

1、布隆过滤器

布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力。

布隆过滤器

2、缓存空对象

当存储层不命中时,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据将会从缓存中获取,从而保护了后端数据源。

缓存空对象

但是这种方式存在两个问题:

  • 如果空值能够被缓存起来,这就意味着需要更多的空间存储更多的键,因为其中可能会有很多空值的键。
  • 即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间窗口不一致的问题,这对于需要保持一致的业务会有影响。

缓存击穿(热点key失效,大量数据集中于一点)

概述

这里和缓存穿透不同,缓存穿透是查询不到数据,所以都去查询数据库,给数据库造成很大压力;而缓存击穿是一个key十分热点(比如微博某明星热搜),缓存在不停地抗着高并发,始终对一个点访问,当这个缓存数据失效后,大量的高并发请求穿破缓存,在很短时间去请求数据库(就好比一梭子子弹打容器上),就像在屏幕中凿了个洞。

当这个热点key失效过期后,大量并发请求前往数据库查询最新数据,查询完后并写入缓存,会使数据库压力过大。

解决方案

1、设置热点数据永不过期
从缓存层面来看,没有设置过期时间,所以不会出现热点key过期后产生的问题。

2、加互斥锁
分布式锁:使用分布式锁,保证对每个key同时只有一个线程去查询后端服务,其它线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。

加互斥锁

缓存雪崩(大量的key几乎同时过期)

概述

缓存雪崩是因为大面积的缓存在一个时间点集中失效,打崩了数据库。

举个简单的例子:如果所有首页的Key失效时间都是12小时,中午12点刷新的,在零点的时候有个秒杀活动会有大量用户涌入,假设当时每秒 6000 个请求,本来缓存在可以扛住每秒 5000 个请求,但是这个时候缓存所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库,数据库必然扛不住,它会报一下警,真实情况可能DBA(管理员)都没反应过来就直接挂了。此时,如果没用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。这就是缓存雪崩。
缓存失效,引起雪崩

解决方案

1、Redis高可用
这个思想的含义就是:既然Redis有可能会挂掉,那我多增设几台Redis,这样一台挂掉了之后其它的还可以继续工作,高可用其实就是搭建的Redis集群。将热点数据均匀分布在不同的Redis库中。

2、限流降级
这个解决方案的思想就是:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其它线程等待。

3、数据预热
数据预热的含义就是在正式部署之前,先把可能高访问的数据预先访问一遍,这样可能大部分的数据就能加载到缓存中。在即将发生大并发访问前手动触发加载缓存中不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀一点。

4、在批量往Redis存数据的时候,把每个key的失效时间都加个随机值,这样保证数据不会在同一时间大面积失效。

关于各种缓存问题的具体解决方案在后面学习后更新

最后修改:2021 年 01 月 21 日 03 : 43 PM
如果觉得我的文章对你有用,请随意赞赏