数据库
首页 > 数据库> > redis应用场景,缓存的各种问题

redis应用场景,缓存的各种问题

作者:互联网

缓存

redis还有另外一个重要的应用领域——缓存

引用来自网友的图解释缓存在架构中的位置

默认情况下,我们的服务架构如下图,客户端请求service,然后service去读取mysql数据库

avatar

问题存在于,数据库性能不够用,数据库是整个架构中最重要的一个环节,它在高并发,高写入频次的时候非常容易崩掉,这是一般的数据库本身的特性所决定的,它们的架构模式注定了不可以承受较大的并发量,所以就有了缓存:

avatar

service与高速的缓存进行交互,如果缓存中有数据直接返回客户端,如果没有才会从MySql中去查询。减小数据库的压力,提升效率,避免宕机。

例如上面章节提到的,超卖问题,有可能瞬间的流量高达上万,我们不可能把这些请求都响应到数据库上,这样速度慢不说,还随时可能宕机。

提到缓存,就不得不说下面的四大缓存名场面,几乎是做缓存必须面对的问题。

缓存击穿

想象一个场景,现在在一个xx办事大厅

张三、李四、王五、赵六、钱钱、刘八、陈九 七个人正在排队

办事处有一个窗口,有一些自动业务机,窗口里面的同志一下子只能接待一个人,而自动业务机因为速度很快可以很快接待很多人。

现在,突然、自动业务机都坏了... 所有人都排到了窗口,这下忙死了窗口里面的同志,直接撂挑子不干了!

这个例子中,自动业务机就像是缓存,起了一个缓冲的作用,业务员就像是数据库,处理能力比自动机器慢,而且很容易炸毛。

缓存击穿就是这样,当某个缓存故障、或者在高峰期缓存突然无效了,就会导致所有请求都跑到数据库去排队,就造成了缓存击穿。

 

缓存相当于给数据库加了一层保护能量罩,敌人进来的时候如果某个地方没有能量,那么如果这个地方的敌人特别多,就会导致缓存击穿。当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用,或者高峰流量,频繁去访问缓存中没有的数据,那么缓存就失去了存在的意义,瞬间所有请求的压力都落在了数据库上,这样会导致数据库连接异常。

解决方案:

缓存穿透

缓存穿透本质上和缓存击穿所面临的问题一样,大量请求落到数据库中。

但是出发点略有不用,缓存穿透的问题是,在高并发下,查询一个不存在的值时,缓存不会被命中,导致大量请求直接落到数据库上,如活动系统里面查询一个不存在的活动。

也就是说,缓存击穿是当数据是存在的,但没有被缓存到,而缓存穿透是去访问根本不存在的值。想象一个场景,黑客截取了一个已经过期的活动的数据接口,然后不断的去请求它,这时候有可能因为这个活动本身已经过期了,缓存不会命中,请求就全部落地到数据库了,这时候就造成了缓存穿透。

缓存穿透的问题解决方案也有很多

直接缓存NULL值

这个比较容易理解,就算是没数据我也缓存一下,你下次过来命中的是空数据。

这种方法需要特别注意,为空的值不能缓存的太久,否则有可能在真的有数据的时候影响了业务正常流程。

布隆过滤器

什么是布隆过滤器

布隆过滤器判断一个值不存在,那么这个值100%不存在

布隆过滤器判断一个值存在,这个值90%是存在的

布隆过滤器本质是一个位数组,位数组就是数组的每个元素都只占用 1 bit 。每个元素只能是 0 或者 1。这样申请一个 10000 个元素的位数组只占用 10000 / 8 = 1250 B 的空间。布隆过滤器除了一个位数组,还有 K 个哈希函数。

等一下,是不是有点绕,不太好理解。

我们知道hash函数可以根据一个值生成一个对应的数字,然后与一个长度可以取模可以得到一个下标值 (你不知道?看看HashMap的实现吧)

或者你根本不知道hash是怎么实现的,没关系,也可以先理解下面的,我们先把这个函数假设为 int getIndex (String value), 根据值获取到一个下标

假设我们现在有一个数组,长度是5,每个元素的值都是0

0 , 0 , 0 , 0 , 0

现在我们数据库中一共有五个id

a , b , c , d , e

现在我们对id们执行getIndex函数可以得到

getIndex(a) = 0

getIndex(b) = 1

getIndex(c) = 1 // 假设函数有一些误差

getIndex(d) = 2

getIndex(e) = 3

想一想,现在来了一个新元素,f 怎么样判断在id里面存在不存在呢?

我们把开始的数组和getIndex关联起来, 将getindex的值作为下标,设置值为1,数组就会变成

1 , 1 , 1 , 1 , 0

然后我们再来判断f是否存在,假设 getIndex(f) = 4

ok了,我们只需要判断数组里的下标4是否是1,是1就存在,0就不存在了嘛

那如果 getIndex(f) = 2 呢? 我们开了上帝视角,很明显f不存在呀。

布隆过滤器不能100%判断一个元素是否真的存在数组中,但能100%判断它不存在与数组中,这取决于hash函数的算法程度

布隆过滤器防止缓存穿透

通过对布隆过滤器的理解,我们能就过滤掉大部分的无效请求了,把数据库中所有的id都getindex解析一次放到布隆过滤器中,请求过来的时候判断,如果不存在就直接返回空就行了

缓存雪崩

如果缓存集中在一段时间内失效,发生大量的缓存穿透,所有的查询都落在数据库上,造成了缓存雪崩。

其实与缓存击穿的理论差不多,都是突然失效导致的击穿数据库。

雪崩与击穿的不同点在于雪崩强调集中失效两个字

想象~ 我现在有三个缓存key存在redis中,过期时间是一天

一天后,由于key有可能是同时设置的缓存,导致这三个key同时失效了,即使我的缓存击穿问题已经解决,这时候因为集中的key失效,也会造成击穿!,这是量级发生了改变,就像x和y的关系, x表示key的多少,y表示请求的多少。。。

解决方案

热度数据

你永远不可能每个缓存都能命中的。什么是好的缓存策略,好的缓存策略是能够识别热点数据,并在热点被读取的时候能够保证命中,这是一个好的缓存策略所必须的条件之一。

 

缓存一致性

 

数据库的数据和缓存的数据是不可能一致的,数据分为最终一致和强一致两类。

强一致 不可以使用缓存

缓存能做的只能保证数据的最终一致性。

我们能做的只能是尽可能的保证数据的一致性。

不管是先删库再删缓存 还是 先删缓存再删库,都可能出现数据不一致的情况,因为读和写操作是并发的,我们没办法保证他们的先后顺序。

具体应对策略根据业务需求来制订。

 

缓存过期和淘汰

 

Redis设置的过期时间。这个key过期时是怎么删除的?

Redis采用的是定期删除,注意不是定时删除,不可能为每一个key做一个定时任务去监控删除,这样会耗尽服务器资源。

默认是每100ms检测一次,遇到过期的key则进行删除,这里的检测也不是顺序检测,而是随机检测。

另外为了防止有漏网之鱼,例如在100ms检查的中间间隙,某个key过期,但同时key访问又进来了,这时触发 惰性删除策略 redis会在读取时判断是否已经过期,过期则直接删除。

内存淘汰是指一部分key在内存不够用的情况下会被Redis自动删除,从而会出现从缓存中查不到数据的情况。

例如我们的服务器内存为2G、但是随着业务的发展缓存的数据已经超过2G了。但是这并不能影响我们程序的运行。所以redis会从key列表中抽取一定的热度低的数据进行淘汰策略,腾出空间存储新的key

 

...持续更新

 

github: https://github.com/294678380/redis-lerning

标签:getIndex,场景,过期,数据库,redis,缓存,key,过滤器
来源: https://www.cnblogs.com/kesimin/p/11394325.html