Redis缓存

toZxl777

于 2024-08-15 21:00:52 发布

阅读量633

点赞数 18

文章标签：缓存 redis 数据库

本文链接：https://blog.csdn.net/2301_79450337/article/details/141229983

版权

Redis最主要的用途

存储数据（内存数据库）
缓存（redis最常用的场景）
消息队列

什么是缓存

缓存 (cache) 是计算机中的⼀个经典的概念. 在很多场景中都会涉及到. 核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅, ⽅便随时读取

举个例⼦: ⽐如我需要去⾼铁站坐⾼铁. 我们知道坐⾼铁是需要反复刷⾝份证的 (进⼊⾼铁站, 检票, 上⻋, 乘⻋过程中, 出站....)

正常来说, 我的⾝份证是放在⽪箱⾥的(⽪箱的存储空间⼤, ⾜够能装). 但是每次刷⾝份证都需要开⼀次⽪箱找⾝份证, 就⾮常不⽅便

因此我就可以把⾝份证先放到⾐服⼝袋⾥. ⼝袋虽然空间⼩, 但是访问速度⽐⽪箱快很多

这样的话每次刷⾝份证我只需要从⼝袋⾥掏⾝份证就⾏了, 就不必开⽪箱了

此时 "⼝袋" 就是 "⽪箱" 的缓存. 使⽤缓存能够⼤⼤提⾼访问效率.

这⾥所说的 "触⼿可及" 是个相对的概念

我们知道, 对于硬件的访问速度来说, 通常情况下:

CPU 寄存器 > 内存 > 硬盘 > ⽹络

那么硬盘相对于⽹络是 "触⼿可及的", 就可以使⽤硬盘作为⽹络的缓存

内存相对于硬盘是 "触⼿可及的", 就可以使⽤内存作为硬盘的缓存

CPU 寄存器相对于内存是 "触⼿可及的", 就可以使⽤ CPU 寄存器作为内存的缓存

速度快的设备，可以作为速度慢的设备的缓存
最常见的是内存作为硬盘的缓存（redis定位）
硬盘也可以作为网络的缓存，浏览器的缓存
浏览器通过http/https从服务器上获取到数据（html，css，js，照片，视频，音频，字体）并进行展示，像这样体积大，又不太改变的数据，就可以保存到浏览器本地（浏览器所在主机的硬盘上），后续再打开这个页面，就不必重新从网络获取上述数据了

"⼆⼋定律"

20%的热点数据, 能够应对 80% 的访问场景

因此只需要把这少量的热点数据缓存起来, 就可以应对⼤多数场景, 从⽽在整体上有明显的性能提升.

使⽤ Redis 作为数据库（MySQL）缓存

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

Answer：

数据库把数据存储在硬盘上, 硬盘的 IO 速度并不快. 尤其是随机访问
如果查询不能命中索引, 就需要进⾏表的遍历, 这就会⼤⼤增加硬盘 IO 次数
关系型数据库对于 SQL 的执⾏会做⼀系列的解析, 校验, 优化⼯作
如果是⼀些复杂查询, ⽐如联合查询, 需要进⾏笛卡尔积操作, 效率更是降低很多
......

因此, 如果访问数据库的并发量⽐较⾼, 对于数据库的压⼒是很⼤的, 很容易就会使数据库服务器宕机

Question：为什么并发量⾼了就会宕机?

Answer：

服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的。所谓的硬件资源包括不限于 CPU, 内存, 硬盘, ⽹络带宽...... ⼀个服务器的硬件资源本⾝是有限的
⼀个请求消耗⼀份资源, 请求多了, ⾃然把资源就耗尽了
后续的请求没有资源可⽤, ⾃然就⽆法正确处理. 更严重的还会导致服务器程序的代码出现崩溃.

Question：

那么如何解决这个问题（提高MySQL能承担的并发量）？

Answer：

开源：引入更多的机器，构成数据库集群

节流：引入缓存，把一些频繁读取的热点数据，保存到缓存上，后续在查询数据的时候，如果缓存中已经存在了，就不再访问MySQL了

Redis 就是⼀个⽤来作为数据库缓存的常⻅⽅案

Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系统资源⽐ MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤
Redis 数据在内存中, 访问内存⽐硬盘快很多
Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则

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

缓存更新策略

如何知道redis中应该存储哪些数据？
如何知道哪些数据是热点数据呢？

定期生成

会把访问的数据，给以日志的形式记录下来；通过日志，把使用到了哪些词，给记录下来，就可以针对这些日志进行统计了，统计每个词出现的频率，再根据频率降序排序，再取出前20%的词，就可以把这些词认为是”热点词“，数据量大，可以使用HDFS，或者hadoop的map-reduce来写代码进行统计/也可以使用基于HDFS的HBASE这样的数据库来写sql统计

此处的数据，就可以根据当前这里统计的维度，来定期更新，按照天级别统计，就每天更新一次；按照月级别统计，就每个月更新一次

写一套离线的流程（shell/python写脚本代码）可以通过定时任务来触发

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

优点：实现起来比较简单，过程可控（缓存中有啥是比较固定的，方便排查问题）
缺点：实时性不够，如果出现一些突发性事件，有一些本来不是热词的内容，成了热词了，新的热词可能会给后面的数据库啥的带来较大的压力

实时生成

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

接下来把⽤⼾每次查询

如果在 Redis 查到了, 就直接返回
如果 Redis 中不存在, 就从数据库查, 把查到的结果同时也写⼊ Redis，不断写redis，就会使redis的内存占用越来越多，逐渐达到内存上限（redis上限可以配置使用多少内存->maxmemory ）

此时如果继续往里插入数据，就会触发问题

为了解决上述问题，redis就引入了”内存淘汰策略“

FIFO (First In First Out) 先进先出把缓存中存在时间最久的 (也就是先来的数据) 淘汰掉
LRU (Least Recently Used) 淘汰最久未使⽤的记录每个 key 的最近访问时间. 把最近访问时间最⽼的 key 淘汰掉
LFU (Least Frequently Used) 淘汰访问次数最少的记录每个 key 最近⼀段时间的访问次数. 把访问次数最少的淘汰掉
Random 随机淘汰从所有的 key 中抽取幸运⼉被随机淘汰掉

理解上述⼏种淘汰策略：

想象你是个皇帝, 有后宫佳丽三千. 虽然你是 "真⻰天⼦", 但是经常宠幸的妃⼦也就那么寥寥数⼈（精⼒有限）

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

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

FIFO: 皇后是最先受宠的. 现在已经年⽼⾊衰了. 皇后失宠
LRU: 统计最近宠幸时间. 皇后(⼀周前), 熹妃(昨天), 安答应(两周前), 华妃(⼀个⽉前). 华妃失宠
LFU: 统计最近⼀个⽉的宠幸次数, 皇后(3次), 熹妃(15次), 安答应(1次), 华妃(10次). 安答应失宠
Random: 随机挑⼀个妃⼦失宠.

这⾥的淘汰策略, 我们可以⾃⼰实现

当然 Redis 也提供了内置的淘汰策略, 也可以供我们直接使⽤. Redis 内置的淘汰策略如下

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

整体来说 Redis 提供的策略和我们上述介绍的通⽤策略是基本⼀致的. 只不过 Redis 这⾥会针对 "过期 key" 和 "全部 key" 做分别处理.