【Redis】Redis典型应用-缓存(cache)

目录

什么是缓存

使用Redis作为缓存

缓存的更新策略

[缓存预热(cache preheating)](#缓存预热(cache preheating))

[缓存穿透(cache penetration)](#缓存穿透(cache penetration))

[缓存雪崩(cache avalanche)](#缓存雪崩(cache avalanche))

[缓存击穿(cache breakdown)](#缓存击穿(cache breakdown))


什么是缓存

缓存 (cache) 是计算机中的⼀个经典的概念. 在很多场景中都会涉及到.

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

举个例⼦:

⽐如我需要去⾼铁站坐⾼铁. 我们知道坐⾼铁是需要反复刷⾝份证的 (进⼊⾼铁站, 检票, 上⻋,

乘⻋过程中, 出站....).

正常来说, 我的⾝份证是放在⽪箱⾥的(⽪箱的存储空间⼤, ⾜够能装). 但是每次刷⾝份证都需

要开⼀次⽪箱找⾝份证, 就⾮常不⽅便.

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

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

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

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

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

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

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

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

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

对于计算机硬件来说, 往往访问速度越快的设备, 成本越⾼, 存储空间越⼩.

缓存是更快, 但是空间上往往是不⾜的. 因此⼤部分的时候, 缓存只放⼀些 热点数据 (访问频繁的数据),就⾮常有⽤了.

关于 "⼆⼋定律"

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

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

能提升.

使用Redis作为缓存

在⼀个⽹站中, 我们经常会使⽤关系型数据库 (⽐如 MySQL) 来存储数据.

关系型数据库虽然功能强⼤, 但是有⼀个很⼤的缺陷, 就是性能不⾼. (换⽽⾔之, 进⾏⼀次查询操作消耗的系统资源较多).

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

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

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

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

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

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

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

服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的. 所谓的硬件资源包括不限于 CPU,

内存, 硬盘, ⽹络带宽......

⼀个服务器的硬件资源本⾝是有限的. ⼀个请求消耗⼀份资源, 请求多了, ⾃然把资源就耗尽

了. 后续的请求没有资源可⽤, ⾃然就⽆法正确处理. 更严重的还会导致服务器程序的代码出现

崩溃

如何让数据库能够承担更⼤的并发量呢? 核⼼思路主要是两个:

开源: 引⼊更多的机器, 部署更多的数据库实例, 构成数据库集群. (主从复制, 分库分表等...)

节流: 引⼊缓存, 使⽤其他的⽅式保存经常访问的热点数据, 从⽽降低直接访问数据库的请求数量

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

Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系统资源⽐

MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤

Redis 数据在内存中, 访问内存⽐硬盘快很多

Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则

客⼾端访问业务服务器, 发起查询请求.

业务服务器先查询 Redis, 看想要的数据是否在 Redis 中存在.

如果已经在 Redis 中存在了, 就直接返回. 此时不必访问 MySQL 了.

如果在 Redis 中不存在, 再查询 MySQL.

按照上述讨论的 "⼆⼋定律" , 只需要在 Redis 中放 20% 的热点数据, 就可以使 80% 的请求不再真正查询数据库了

缓存的更新策略

定期生成

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

以搜索引擎为例.

⽤⼾在搜索引擎中会输⼊⼀个 "查询词", 有些词是属于⾼频的, ⼤家都爱搜(鲜花, 蛋糕, 同城交

友, 不孕不育...). 有些词就属于低频的, ⼤家很少搜.

搜索引擎的服务器会把哪个⽤⼾什么时间搜了啥词, 都通过⽇志的⽅式记录的明明⽩⽩. 然后

每隔⼀段时间对这期间的搜索结果进⾏统计 (⽇志的数量可能⾮常巨⼤, 这个统计的过程可能

需要使⽤ hadoop 或者 spark 等⽅式完成). 从⽽就可以得到 "⾼频词表" .

这种做法实时性较低. 对于⼀些突然情况应对的并不好.

⽐如春节期间, "春晚" 这样的词就会成为⾮常⾼频的词. ⽽平时则很少会有⼈搜索 "春晚".

实时生成

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

接下来把⽤⼾每次查询:

如果在 Redis 查到了, 就直接返回.

如果 Redis 中不存在, 就从数据库查, 把查到的结果同时也写⼊ Redis.

如果缓存已经满了(达到上限), 就触发缓存淘汰策略, 把⼀些 "相对不那么热⻔" 的数据淘汰掉.

按照上述过程, 持续⼀段时间之后 Redis 内部的数据⾃然就是 "热⻔数据" 了.

通⽤的淘汰策略主要有以下⼏种:

FIFO (First In First Out) 先进先出

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

LRU (Least Recently Used) 淘汰最久未使⽤的

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

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

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

Random 随机淘汰

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

Redis 内置的淘汰策略如下:

volatile-lru 当内存不⾜以容纳新写⼊数据时,从设置了过期时间的key中使⽤LRU(最近最

少使⽤)算法进⾏淘汰

allkeys-lru 当内存不⾜以容纳新写⼊数据时,从所有key中使⽤LRU(最近最少使⽤)算法进

⾏淘汰.

volatile-lfu 4.0版本新增,当内存不⾜以容纳新写⼊数据时,在过期的key中,使⽤LFU算法

进⾏删除key.

volatile-random 当内存不⾜以容纳新写⼊数据时,从设置了过期时间的key中,随机淘汰数

据.

allkeys-random 当内存不⾜以容纳新写⼊数据时,从所有key中随机淘汰数据.

volatile-ttl 在设置了过期时间的key中,根据过期时间进⾏淘汰,越早过期的优先被淘汰.

(相当于 FIFO, 只不过是局限于过期的 key)

noeviction 默认策略,当内存不⾜以容纳新写⼊数据时,新写⼊操作会报错.

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

缓存预热(cache preheating)

使⽤ Redis 作为 MySQL 的缓存的时候, 当 Redis 刚刚启动, 或者 Redis ⼤批 key 失效之后, 此时由于Redis ⾃⾝相当于是空着的, 没啥缓存数据, 那么 MySQL 就可能直接被访问到, 从⽽造成较⼤的压⼒.因此就需要提前把热点数据准备好, 直接写⼊到 Redis 中. 使 Redis 可以尽快为 MySQL 撑起保护伞

热点数据可以基于之前介绍的统计的⽅式⽣成即可. 这份热点数据不⼀定⾮得那么 "准确", 只要能帮助MySQL 抵挡⼤部分请求即可. 随着程序运⾏的推移, 缓存的热点数据会逐渐⾃动调整, 来更适应当前情况

缓存穿透(cache penetration)

什么是缓存穿透

访问的 key 在 Redis 和 数据库中都不存在. 此时这样的 key 不会被放到缓存上, 后续如果仍然在访问该key, 依然会访问到数据库.这就会导致数据库承担的请求太多, 压⼒很⼤.这种情况称为 缓存穿透.

产生原因

原因可能有⼏种:

业务设计不合理. ⽐如缺少必要的参数校验环节, 导致⾮法的 key 也被进⾏查询了.

开发/运维误操作. 不⼩⼼把部分数据从数据库上误删了.

⿊客恶意攻击.

如何解决:

针对要查询的参数进⾏严格的合法性校验. ⽐如要查询的 key 是⽤⼾的⼿机号, 那么就需要校验当前key 是否满⾜⼀个合法的⼿机号的格式.

针对数据库上也不存在的 key , 也存储到 Redis 中, ⽐如 value 就随便设成⼀个 "". 避免后续频繁访问数据库.

使⽤布隆过滤器先判定 key 是否存在, 再真正查询.

缓存雪崩(cache avalanche)

什么是缓存雪崩

短时间内⼤量的 key 在缓存上失效, 导致数据库压⼒骤增, 甚⾄直接宕机.

本来 Redis 是 MySQL 的⼀个护盾, 帮 MySQL 抵挡了很多外部的压⼒. ⼀旦护盾突然失效了,MySQL⾃⾝承担的压⼒骤增, 就可能直接崩

产生原因

⼤规模 key 失效, 可能性主要有两种:

Redis 挂了.

Redis 上的⼤量的 key 同时过期.这种可能是短时间内在 Redis 上缓存了⼤量的 key, 并且设定了相同的过期时间.

如何解决:

部署⾼可⽤的 Redis 集群, 并且完善监控报警体系.

不给 key 设置过期时间 或者 设置过期时间的时候添加随机时间因⼦.

缓存击穿(cache breakdown)

什么是缓存击穿

相当于缓存雪崩的特殊情况. 针对热点 key , 突然过期了, 导致⼤量的请求直接访问到数据库上, 甚⾄引起数据库宕机.

如何解决:

基于统计的⽅式发现热点 key, 并设置永不过期.

进⾏必要的服务降级. 例如访问数据库的时候使⽤分布式锁, 限制同时请求数据库的并发数.


今天对Redis作为缓存(cache)的分享到这就结束了,希望大家读完后有很大的收获,也可以在评论区点评文章中的内容和分享自己的看法;个人主页还有很多精彩的内容。您三连的支持就是我前进的动力,感谢大家的支持!!!

相关推荐
weixin_414321983 分钟前
Linux 编译Ubuntu24内核
linux·运维·服务器
东阳马生架构1 小时前
MySQL底层概述—1.InnoDB内存结构
java·数据库·mysql
standxy2 小时前
通过轻易云平台实现聚水潭数据高效集成到MySQL的技术方案
android·数据库·mysql
itwangyang5202 小时前
2025 - 科研神器 - 批量处理 PDF、SVG、PNG 和 JPG 文件,将它们转换为彩色 TIFF 文件,并保存到指定的 tiff 文件夹中
数据库·pdf
xiaozhiwise2 小时前
Makefile 之 join
linux
时光の尘2 小时前
C语言菜鸟入门·关键字·int的用法
c语言·开发语言·数据结构·c++·单片机·链表·c
C++忠实粉丝2 小时前
计算机网络socket编程(6)_TCP实网络编程现 Command_server
网络·c++·网络协议·tcp/ip·计算机网络·算法
痞老板A小安装C43 小时前
redis的大key和热key问题解决方案
数据库·redis·bootstrap
飞升不如收破烂~3 小时前
Redis的String类型和Java中的String类在底层数据结构上有一些异同点
java·数据结构·redis
feilieren3 小时前
DataGrip 连接 Redis、TongRDS
数据库·redis·缓存