Redis缓存

小笨猪-

于 2024-10-04 15:44:30 发布

阅读量977

点赞数 10

分类专栏： Redis 文章标签：缓存 redis 数据库分布式

本文链接：https://blog.csdn.net/qq_74812898/article/details/142702788

版权

Redis 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

概念

核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅,⽅便随时读取.

速度快的设备,可以作为速度慢的设备的缓存

(CPU寄存器>内存>硬盘>网络)

最常见的是,使用内存作为硬盘的缓存

硬盘也可以作为网络的缓存,浏览器的缓存

浏览器通过http/https从服务器上获取到数据(html,css,js,图片,视频...),像图片这样体积大,又不太改变的数据,就可以保存到浏览器本地(浏览器所在主机的硬盘上),后续再打开这个页面,就不必重新从网络上获取上述数据了

缓存的意义:二八定律

缓存速度虽然快,但是空间小,20%的数据,可以应对80%的请求

使用Redis作为缓存

通常使用redis作为数据库的缓存

为什么说关系型数据库性能不⾼?

1. 数据库把数据存储在硬盘上,硬盘的IO速度并不快.尤其是随机访问.

2. 如果查询不能命中索引,就需要进⾏表的遍历,这就会⼤⼤增加硬盘IO次数.

3. 关系型数据库对于SQL的执⾏会做⼀系列的解析,校验,优化⼯作.

4. 如果是⼀些复杂查询,⽐如联合查询,需要进⾏笛卡尔积操作,效率更是降低很多.

因为mysql等数据库,效率比较低,所以承担的并发量就有限.一旦请求数量多了,数据库的压力就会很大,甚至很容易宕机了

服务器每次处理一个请求,一定要消耗一些硬件资源(cpu,内存,硬盘...),任意一种资源的消耗超出了机器能提供的上限,机器就很容器出现故障了

如何提高mysql能承担的并发量?

开源:引入更多的机器,构成数据库集群
节流:引入缓存,使用其它的方式保存经常访问的热点数据,从而降低直接访问数据库的请求数量,Redis 就是⼀个⽤来作为数据库缓存的常⻅⽅案

虽然redis只能存少数数据,但是大部分请求都是使用的这少数的热点数据

Redis能⽀持的并发量更⼤:

Redis数据在内存中,访问内存⽐硬盘快很多.
Redis只是⽀持简单的key-value存储,不涉及复杂查询的那么多限制规则.

注意:

缓存是⽤来加快"读操作"的速度的.如果是"写操作",还是要⽼⽼实实写数据库,缓存并不能提⾼性能.

缓存的更新策略

如何知道redis中应该存储哪些数据?

如何知道哪些数据是热点数据呢?

1.定期生成

每隔⼀定的周期(⽐如⼀天/⼀周/⼀个⽉),对于访问的数据频次进⾏统计.挑选出访问频次最⾼的前N%的数据.

会把访问的数据,给以日志的形式记录下来

然后对日志进行统计,统计某段时间,每个词出现的频率,再根据频率降序排序,取出前N%的词,就可以把这些词认为是"热点词"

数据量可以很大,一台机器存不下,就需要使用分布式系统来存储这些日志(HDFS),再使用hadoop的map-reduce来写代码,进行统计,也可以使用基于HDFS的HBASE这样的数据库来写sql统计

把这些热点词,涉及到的结果,,提前拎出来,放到类似于redis这样的缓存中

此处的数据,就可以根据当前这里统计的维度,来定期更新

写一套离线的流程(往往使用shell,python写脚本代码),可以通过定时任务来触发

a)完成统计热词的过程
b)根据热词,找到搜索结果的数据
c)把得到缓存数据同步到缓存服务器上
d)控制这些缓存服务器自动重启

优点:

实现比较简单,过程可控(缓存中的有什么内容比较固定),方便排查问题

缺点:

实时性不够,如果出现一些突发性事件,有一些本来不是热词的内容,成了热词,新的热词就可能给后面的数据库带来较大的压力

2.实时生成

先给缓存设定容量上限(可以通过Redis配置⽂件的 maxmemory 参数设定):

如果在redis查到了,就直接返回
如果redis不存在,就从数据库查,把查到的结果同时也写入redis

这样不停的写redis,就会使redis的内存占用越来越多,逐渐达到内存上限

此时继续往里面插入数据,就会触发问题,为了解决上述情况,redis就引入了"内存淘汰策略"

[经典面试题]内存淘汰策略

FIFO (First In First Out) 先进先出

把缓存中存在时间最久的(也就是先来的数据)淘汰掉.

LRU(LeastRecentlyUsed)淘汰最久未使⽤的

记录每个key的最近访问时间.把最近访问时间最⽼的key淘汰掉.

LFU(LeastFrequently Used)淘汰访问次数最少的

记录每个key最近⼀段时间的访问次数.把访问次数最少的淘汰掉.

Random随机淘汰

从所有的key中抽取幸运⼉被随机淘汰掉.

以甄嬛传为例

后宫佳丽三千,相当于数据库中的全量数据.经常宠幸的妃⼦相当于热点数据,是放在缓存中的.

今年选秀的⼀批新的⼩主,其中有⼀个被你看上了.宠信新⼈,⾃然就需要有旧⼈被冷落.到底谁是要被冷落的⼈呢?

• FIFO:皇后是最先受宠的.现在已经年⽼⾊衰了.皇后失宠.

• LRU:统计最近宠幸时间.皇后(⼀周前),熹妃(昨天),安答应(两周前),华妃(⼀个⽉前).华妃失宠. • LFU:统计最近⼀个⽉的宠幸次数,皇后(3次),熹妃(15次),安答应(1次),华妃(10次).安答应失宠.

• Random:随机挑⼀个妃⼦失宠.

具体采用哪种策略,结合实际场景

Redis内置的淘汰策略如下:

策略	含义
volatile-lru	当内存不⾜以容纳新写⼊数据时，从设置了过期时间的key中使⽤LRU（最近最少使⽤）算法进⾏淘汰(设置了过期时间的就算,包括过期时间还没到的)
allkeys-lru	当内存不⾜以容纳新写⼊数据时，从所有key中使⽤LRU（最近最少使⽤）算法进⾏淘汰.
volatile-lfu	当内存不⾜以容纳新写⼊数据时，在过期的key中，使⽤LFU算法进⾏删除key
allkeys-lfu	内存不⾜以容纳新写⼊数据时，从所有key中使⽤LFU算法进⾏淘汰
volatile-random	当内存不⾜以容纳新写⼊数据时，从设置了过期时间的key中，随机淘汰数据.
allkeys-random	当内存不⾜以容纳新写⼊数据时，从所有key中随机淘汰数据.
volatile-ttl	在设置了过期时间的key中，根据过期时间进⾏淘汰，越早过期的优先被淘汰. (相当于FIFO,只不过是局限于过期的key)
noeviction	默认策略，当内存不⾜以容纳新写⼊数据时，新写⼊操作会报错,不适合实时更新缓存