redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿

🧸欢迎来到dream_ready的博客，📜相信您对这篇博客也感兴趣o (ˉ▽ˉ；)

📜Redis 学习笔记，超基础，适合零基础和弱基础学习

目录

1、Redis最主要的用途

2、什么是缓存？

2.1、此处介绍一下浏览器的缓存

3、为什么mysql等数据库慢呢？

3.1、为什么说关系型数据库性能不高？

3.2、为什么要引入redis，而不是全部的查询操作都经过mysql呢？

4、如何提高mysql能承担的并发量？

5、如何知道哪些数据是热点数据呢？

5.1、定期生成

5.2、实时生成

5、通用的内存淘汰策略

 6、redis中内置的淘汰策略

7、缓存使用注意事项，缓存可能出现的四大问题(专业术语)

8、缓存预热

9、 缓存穿透

10、 缓存雪崩

11、缓存击穿（缓存瘫痪）

1、Redis最主要的用途

有三个方面：

• 存储数据(内存数据库)
• 缓存(redis最常用的场景)
• 消息队列

而redis和缓存间存在什么关系呢？redis在发挥作用时会遇到哪些问题？

2、什么是缓存？

缓存是一种临时存储数据的技术，用于在后续请求中快速获取先前检索或计算的数据，从而加速访问速度。

在计算机系统中，缓存可以出现在多个层次，包括硬件缓存、操作系统缓存和应用程序级别的缓存。这种机制的基本思想是通过存储一些计算结果或频繁访问的数据，减少对更慢的存储系统（如数据库或磁盘）的访问次数，从而提高系统的性能和响应速度

其实缓存是相对的概念

• 比如拿读取速度排序： CPU寄存器 > 内存 > 硬盘 > 网络
• 速度快的设备，可以作为速度慢的设备的缓存
• 最常见的是，使用内存作为硬盘的缓存(redis定位)
• 硬盘也可以作为网络的缓存

2.1、此处介绍一下浏览器的缓存

浏览器缓存是指浏览器在本地存储已访问过的网页资源，以便在后续访问相同页面时能够更快地加载内容。浏览器缓存有助于提高网页加载速度、减轻服务器负担，并提升用户体验

浏览器通过http/https等从服务器上获取到数据(html,css,js,图片，视频，音频，字体…)并进行展示

优点举例：

        像图片这样的体积大，又不太改变的数据，就可以保存到浏览器本地(浏览器所在主机的硬盘上)，后续再打开这个页面,就不必重新从网络获取上述数据了

缺点举例：

        如果前端代码有所修改，或者图片等内容有所改变，用户看到的可能仍然是原来的网页，这就是因为浏览器的缓存，它有些数据默认还是用的缓存中的数据，没有及时更新，导致残留的是旧版本的前端代码，引发bug(可以按ctrl+F5来强制刷新浏览器缓存)

缓存速度虽然快，但是空间小

通常使用redis作为mysql等数据库的缓存,因为mysql相比redis来说慢很多

3、为什么mysql等数据库慢呢？

此处拿类似mysql的这种关系型数据库举例

3.1、为什么说关系型数据库性能不高？

• 数据库把数据存储在硬盘中，硬盘的IO速度并不快，尤其是随机访问(硬件)
• 如果查询不能命中索引，就需要进行表的遍历，这就会大大增加硬盘IO次数(硬件)
• 关系型数据库对于SQL的执行会做一系列的解析，校验，优化工作(软件)
• 如果是一些复杂查询，比如联合查询，需要进行笛卡尔积操作，效率更是降低很多(软件)
• ……

3.2、为什么要引入redis，而不是全部的查询操作都经过mysql呢？

• 因为mysql等数据库，效率比较低，所以承担的并发量就有限，一旦请求数量多了，数据库的压力就会很大，甚至很容易就泵机了
• 服务器每次处理一个请求，一定都要消耗一些硬件资源(cpu，内存，硬盘，网络…)
• 任意一种资源的消耗超出了机器能提供的上限，机器就很容易出现故障了

4、如何提高mysql能承担的并发量？

四个大字： 开源   节流

• 开源：引入更多的机器，构成数据库集群
• 节流：引入缓存，就是典型的方案，把一些频繁读取的热点数据，保存到缓存上                         后续在查询数据的时候，如果缓存中已经存在了，就不再访问mysql了

客户端发送的查询数据等请求，会先到达redis，如果redis没有，再查mysql

虽然redis上只能存少数数据，但是大部分请求都是使用的这少数的热点数据(二八原则)

5、如何知道哪些数据是热点数据呢？

• 客户端发送的查询数据等请求，会先到达redis，如果redis没有，再查mysql
• 虽然redis上只能存少数数据，但是大部分请求都是使用的这少数的热点数据(二八原则)

这是依靠缓存的更新策略来进行实现的

• 定期生成
• 定时生成

5.1、定期生成

会把访问的数据，以日志的形式记录下来，然后针对某个时间段或时间点访问高频的数据存储到redis里

举例：

• 通过日志，把都使用了哪些词，给记录下来
• 然后就可以针对这些日志进行统计了
• 统计这一天，每个词出现的频率，再根据频率降序排序
• 再取出前20%的词
• 就可以把这些词认为是“热点词”
• 接下来就可以把这些热点词，涉及到的搜索结果提前拎出来
• 就可以放到类似于“redis”这样的缓存中了
• 以上这些步骤可以用下面操作来实现(只是举例，实际肯定更麻烦)：
• 写一套离线的流程(往往使用shell，python写脚本代码…)

可以通过定时任务来触发：

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

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

缺点举例：

        比如春节晚会，一般就是过年这几天，但是访问量可能会达到一年中最高的数量，但是过完年后几乎没人再去搜索，它就不适合继续当热词了，但如果按照定时生成策略的话，它会一直是热词

5.2、实时生成

• 查询数据时：
• 如果在redis查到了，就直接返回
• 如果 redis 中不存在，就从数据库查，把查到的结果同时也写入Redis
• 经过一段时间的“动态平衡”，redis中的key就逐渐都成为热点数据了

缺点：这样不停地写redis，就会使redis的内存占用越来越多，逐渐达到内存上限(不一定是机器内存上限，redis中也可以配置，最多使用多少内存)

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

5、通用的内存淘汰策略

为了解决生成热点数据方法带来的缺点，redis就引入了”内存淘汰策略“

主要有以下几种，下列策略并非局限于Redis，其他缓存也可以按这些策略展开

 这其中的淘汰策略，Random太随机了，不太合理，而LFU是按照次数来衡量的，是最靠谱的

 6、redis中内置的淘汰策略

• lru补充：这句话描述的设置了过期时间的key，是指设置了过期时间的就算，包括过期时间还没到的
• noeviction补充： 这是默认选项，不适合于实时更新缓存

redis里面，有一个配置项，就可以设置redis采取上述那种策略淘汰内存数据

具体采取哪种策略，结合实际场景来具体问题具体分析

相对来说，实时生成是没有定期生成更可控的，更多情况下还是使用定期生成

7、缓存使用注意事项，缓存可能出现的四大问题(专业术语)

• 缓存预热
• 缓存穿透
• 缓存雪崩
• 缓存击穿

8、缓存预热

避免服务器刚启动或者大批key失效时没有数据，导致所有的请求都打给mysql，把mysql搞挂了

缓存中的数据是定期生成和定时生成两种实现方式(其余方式也有，此处以这两种举例)

• 定期生成，这种情况，不涉及”预热“
• 定时生成就涉及预热

redis服务器首次接入之后，服务器里是没有数据的

此时，所有的请求都会打给mysql，从而造成数据库较大的压力

当然，随着时间推移，redis上的数据越积累越多，mysql承担的压力就逐渐减小了

缓存预热，就是用来解决上述问题的

• 它把定期生成和实时生成结合一下
• 先通过离线的方式，通过一些统计的途径，先把热点数据找到一批，导入到redis中
• 此时导入的这批热点数据，就能帮mysql承担很大的压力了
• 随着时间的推移，逐渐使用新的热点数据淘汰掉旧的数据

9、 缓存穿透

访问的key在redis和数据库中都不存在，这个key肯定也没有被更新到redis中

这次查询没有，下次查询，仍然没有，如果像这样的数据，存在很多，并且还反复查询，一样也会给mysql带来很大的压力

为何产生？

原因可能有以下几种：

• 业务设计不合理，比如缺少必要的参数校验环节，导致非法的key也被进行查询了
• 开发/运维误操作，不小心把部分数据从数据库中误删了
• 黑客恶意攻击

如何解决？

通过改进业务/加强监控报警  => 有用，但属于亡羊补牢

更靠谱的方案(降低问题的严重性)

• 如果发现这个key，在redis和mysql上都不存在，仍然写入redis中，value设成一个非法值(比如””)
• 还可以引入布隆过滤器，每次查询redis/mysql之前都先判定一下key是否在 布隆过滤器中 存在

(把所有的key都插入到布隆过滤器中)

布隆过滤器，本质上是结合了 hash + bitmap

以比较小的空间开销，比较快的时间速度，实现针对key是否存在的判定

10、 缓存雪崩

由于在短时间内，redis上大规模的key失效，导致缓存命中率陡然下降，并且mysql的压力迅速上升，甚至直接泵机

为何产生？

原因可能有以下几种：

1. redis直接挂了   = >  redis泵机/redis集群模式下大量节点泵机
2. redis好着呢，但是可能之前短时间内设置了很多key给redis，并且设置的过期时间是相同的

补：为什么设置过期时间？

给redis里设置key作为缓存的时候，有的时候为了考虑缓存的时效性，就会设置过期时间(和redis内存淘汰机制，是配合使用的)

如何解决？

• 加强监控报警，加强redis集群可用性的保证
• 不给key设置过期时间/设置过期时间的时候添加随机的因子(避免同一时刻过期)

11、缓存击穿（缓存瘫痪）

缓存击穿(翻译的不太合适)，也可以称之为缓存瘫痪(合适)

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

如何解决？

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

补：

1、解决方案1往往需要服务器结构做出较大的调整

2、解决方案2中的服务降级指的是可能本身服务器的功能有十个，但是在特定情况下，适当的关闭一些不重要的功能，只保留核心功能

       功能/服务降级也可以称之为省电模式

       访问数据库的时候使用分布式锁  = >  通过分布式锁，限制数据库的访问频率

🧸欢迎您于百忙之中阅读这篇博客，📜希望这篇博客给您带来了一些帮助，祝您生活愉快！

代码007普通

打赏 收藏 海报 链接