Redis 典型应用 - 缓存(cache)

devtools/2024/11/16 1:16:28/

一、什么是缓存

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

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

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

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

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

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

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

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

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

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

关于"⼆⼋定律"

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

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

二、 使⽤Redis作为缓存

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

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

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

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

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

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

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

⼀个服务器的硬件资源本⾝是有限的.⼀个请求消耗⼀份资源,请求多了,⾃然把资源就耗尽 了.后续的请求没有资源可⽤,⾃然就⽆法正确处理.更严重的还会导致服务器程序的代码出现 崩溃

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

  • 开源:引⼊更多的机器,部署更多的数据库实例,构成数据库集群.(主从复制,分库分表等...)
  • 节流:引⼊缓存,使⽤其他的⽅式保存经常访问的热点数据,从⽽降低直接访问数据库的请求数量.

实际开发中,这两种⽅案往往是会搭配使⽤的.

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

Redis访问速度⽐MySQL快很多.或者说处理同⼀个访问请求,Redis消耗的系统资源⽐ MySQL少很多.因此Redis能⽀持的并发量更⼤.

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

 就像⼀个"护盾"⼀样,把MySQL给罩住了.

  •  客⼾端访问业务服务器,发起查询请求.
  • 业务服务器先查询Redis,看想要的数据是否在Redis中存在.
    • 如果已经在Redis中存在了,就直接返回.此时不必访问MySQL了.
    • 如果在Redis中不存在,再查询MySQL.

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

注意!

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

 

三、缓存的更新策略

接下来还有⼀个重要的问题,到底哪些数据才是"热点数据"呢?

3.1、定期⽣成

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

以搜索引擎为例.

⽤⼾在搜索引擎中会输⼊⼀个"查询词",有些词是属于⾼频的,⼤家都爱搜.有些词就属于低频的,⼤家很少搜.

搜索引擎的服务器会把哪个⽤⼾什么时间搜了啥词,都通过⽇志的⽅式记录的明明⽩⽩.然后 每隔⼀段时间对这期间的搜索结果进⾏统计(⽇志的数量可能⾮常巨⼤,这个统计的过程可能 需要使⽤hadoop或者spark等⽅式完成).从⽽就可以得到"⾼频词表"

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

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

3.2、实时⽣成

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

接下来把⽤⼾每次查询:

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

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

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

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

下列策略并⾮局限于Redis,其他缓存也可以按这些策略展开

 1)FIFO (First In First Out) 先进先出

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

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

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

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

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

4)Random随机淘汰

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

这⾥的淘汰策略,我们可以⾃⼰实现.当然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"做分别处理.

四、缓存预热,缓存穿透,缓存雪崩 和 缓存击穿

4.1、关于缓存预热(Cache preheating)

什么是缓存预热

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

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

4.2、关于缓存穿透 (Cache penetration)

什么是缓存穿透?

        访问的key在Redis和数据库中都不存在.此时这样的key不会被放到缓存上,后续如果仍然在访问该 key, 依然会访问到数据库.

这就会导致数据库承担的请求太多,压⼒很⼤.

这种情况称为 缓存穿透.

为何产⽣?

原因可能有⼏种:

  • 业务设计不合理.⽐如缺少必要的参数校验环节,导致⾮法的key也被进⾏查询了.
  • 开发/运维误操作.不⼩⼼把部分数据从数据库上误删了.
  • ⿊客恶意攻击.

如何解决?

  • 针对要查询的参数进⾏严格的合法性校验.⽐如要查询的key是⽤⼾的⼿机号,那么就需要校验当前 key 是否满⾜⼀个合法的⼿机号的格式.
  • 针对数据库上也不存在的key,也存储到Redis中,⽐如value就随便设成⼀个"".避免后续频繁访 问数据库.
  • 使⽤布隆过滤器先判定key是否存在,再真正查询.

关于布隆过滤器,在数据结构进阶,有具体介绍.此处就不再赘述.

简单的说,布隆过滤器是结合了hash+bitmap的思想,能够⽤较少的空间,判定某个元素是否 存在.

4.3、 关于缓存雪崩(Cache avalanche)

什么是缓存雪崩

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

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

 为何产⽣?

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

  • Redis挂了
  • Redis上的⼤量的key同时过期.

为啥会出现⼤量的key同时过期?

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

如何解决?

  • 部署⾼可⽤的Redis集群,并且完善监控报警体系.
  • 不给key设置过期时间或者设置过期时间的时候添加随机时间因⼦.

4.4、关于缓存击穿(Cache breakdown)

什么是缓存击穿?

此处把breakdown翻译成"击穿",个⼈以为并⾮是⼀个好的选择.容易和缓存穿透混淆. 翻译成"瘫痪"或者"崩溃"也许更合适⼀些.

breakdownn.(汽⻋或机器的)故障,损坏;(关系的)破裂,(系统的)瘫痪;精神崩 溃,(健康、体⼒等的)衰竭;细⽬,分类;分解;跺脚曳步舞

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

如何解决?

  • 基于统计的⽅式发现热点key,并设置永不过期
  • 进⾏必要的服务降级.例如访问数据库的时候使⽤分布式锁,限制同时请求数据库的并发数.

http://www.ppmy.cn/devtools/134303.html

相关文章

时序预测 | Python基于CNN-transformer时间序列预测

时序预测 | Python基于CNN-transformer时间序列预测 目录 时序预测 | Python基于CNN-transformer时间序列预测预测效果基本介绍参考资料 预测效果 基本介绍 时序预测 | Python基于CNN-transformer时间序列预测 Cnn-transformer-自适应稀疏自注意力ASSA-对比归一化contranorm预…

docker打包nginx版wordpress

官方打包的wordpress的docker版是基于apache,在低配的机器上容易挂掉。所以考虑nginx Dockerfile # 更改基础镜像为PHP 8.x FPM Alpine FROM php:8.2-fpm-alpine# 更新并安装PHP依赖,注意检查扩展与PHP 8.x的兼容性 # 这里不用php8.3 因为安装imagick有…

Mysql个人八股总结

1.一条 SQL 查询语句是如何执行的 第一步:连接器 连接数据库:当用户发起SQL查询时,连接器负责与数据库建立连接,验证用户身份并准备执行查询。 第二步:查询缓存 检查查询缓存:在执行查询之前&#xff0…

sql专题 之 sql的执行顺序

文章目录 sql的执行顺序sql语句的格式实际的执行顺序:虚拟表 vs 数据集虚拟表 结果集总结嵌套查询在sql查询中的执行顺序 前文我们了解了sql常用的语句,这次我们对于这些语句来个小思索 戳这里→ sql专题 之 常用命令 sql的执行顺序 SQL语句的执行顺序是…

【PGCCC】Postgresql 物理流复制

postgresql 提供了主从复制功能,有基于文件的拷贝和基于 tcp 流的数据传输两种方式。两种方式都是传输 wal 数据,前者是等待生成一个完整的wal文件后,才会触发传输,后者是实时传输的。可以看出来基于文件方式的延迟会比较高&#…

认识HTML(简介)

HTML(超文本标记语言——HyperText Markup Language)是构成 Web 世界的一砖一瓦。它定义了网页内容的含义和结构。除 HTML 以外的其他技术则通常用来描述一个网页的表现与展示效果(如 CSS),或功能与行为(如…

基于SpringBoot+Vue的船运物流管理系统(带1w+文档)

基于SpringBootVue的船运物流管理系统(带1w文档) 基于SpringBootVue的船运物流管理系统(带1w文档) 现今,互联网在我们的日常生活占据着日益重要的地位,我们也越来越离不开对移动设备、电脑等上网设备的使用。传统的船运物流管理系统模式主要依靠管理人员…

Ceph后端两种存储引擎介绍

Ceph是一个可靠的、自治的、可扩展的分布式存储系统,它支持文件系统存储、块存储、对象存储三种不同类型的存储,以满足多样存储的需求。在Ceph的存储架构中,FileStore和BlueStore是两种重要的后端存储引擎,下面将分别进行详细介绍…