深入学习 Redis - 如何使用 Redis 作缓存？缓存更新策略？使用需要注意哪些问题（工作/重点）

朱雀 2024-03-02 04:33 56阅读 0赞

**目录**

一、Redis 作为缓存

1.1、缓存的基本概念

1.1.1、理解

1.1.2、缓存存什么样的数据？二八定律

1.2、如何使用 redis 作为缓存

1.3、缓存更新策略（redis 内存淘汰机制 / 重点）

1.3.1、定期生成

1.3.2、实时生成

内存淘汰策略（经典面试）

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

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

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

4. Random 随机淘汰

深入理解淘汰策略：

redis 中采用的淘汰策略

1.4、缓存使用的注意事项（重点）

1.4.1、缓存预热（Cache preheating）

1.4.2、缓存穿透（Cache penetration）

1.4.3、缓存雪崩（Cache avalanche）

1.4.4、缓存击穿（Cache breakdown）

--------------------

## 一、Redis 作为缓存 ##

--------------------

### 1.1、缓存的基本概念 ###

#### 1.1.1、理解 ####

缓存可以理解为，将常用的数据从放到一个访问速度更快的的地方，方便更快的随时读取.

也就是说，**速度快的设备，可以作为速度慢的设备的缓存，加快读取速度。**在计算机硬件中的访问速度如下：

*  CPU 寄存器 > 内存 > 硬盘 > 网络

最常见的就是，使用 内存 作为 硬盘 的缓存，比如 redis.....

当然 硬盘 也可以作为 网络 的缓存，比如浏览器通过 http/https 从服务器上获取数据（html、css、js、图片、视频......）并进行展示，像这样体积大，但又不经常改变的数据，就可以保存到浏览器本地硬盘上，后续在打开这个页面，就不必重新从网络获取上述数据了.

#### 1.1.2、缓存存什么样的数据？二八定律 ####

缓存速度虽然快，但是空间小，因此大部分情况，缓存只存放一些热点数据，就非常有用了.

这里就不得不提一下二八定律了，就是说缓存 **只需要存储 20% 的热点数据，就可以应对 80% 的请求.**

### 1.2、如何使用 redis 作为缓存 ###

**我们通常使用 redis 作为 数据库（mysql）的缓存.**

这是由于，数据库是非常重要的组件，但是速度又很慢，一旦短时间内有大量请求来临，就有可能使数据库压力过大，导致宕机.

> 为什么会压力过大，导致宕机？

服务器每次处理一个请求，都要消耗一些硬件资源（cpu、内存、硬盘、网络......），任何一种资源的消耗超出了机器提供的上限，就很容易出现故障了.

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

1. 开源：引入更多的机器，构成数据库集群，例如 主从复制（即使主节点宕机，也可以通过提升从节点为主节点来解决）、分库分表.....

2. 节流：引入缓存，就是典型的方案. 把一些频繁的读取的热点数据保存到缓存上，后续再查询数据的时候，如果缓存已经存在了，就直接把从缓存上读到的数据返回，也就不在访问 mysql 了.

![d056707ee89a4f6cbd182a27ff96d3e8.png][]

### 1.3、缓存更新策略（redis 内存淘汰机制 / 重点） ###

实际的工作中，如何知道 redis 中应该存储哪些数据？如何知道哪些数据使热点数据？

这就得看你使用缓存的哪种更新策略了~

#### 1.3.1、定期生成 ####

**每隔⼀定的周期 (比如⼀天/⼀周/⼀个⽉) , 对于访问的数据频次进⾏统计，并以日志的形式记录下来，最后挑选出访问频次最⾼的前 N% 的数据，放到缓存中.**

例如搜索引擎.

*搜索引擎的 “查询词” 就是要关注的 “访问的数据”，通过日志，把每天（也可以按一周、一月）都使用到了哪些词，给记录下来，就可以针对这些日志进行统计（这里的统计数据量非常大，需要写个程序来统计，数量大到可能需要使用分布式系统来存储日志 HDFS），统计这一天中，每个词出现的频率，再根据频率降序排序，提取出 前 20% 的词，就可以认为这些词是 “热点词” .*

*接下来就可以把这些热点词，以及涉及到的搜索结构都提前拎出来，放到类似 “ redis” 这样的缓存中了。*

> 如何定期统计呢？

可以写一套离线流程（往往使用 shell，python 写脚本代码），然后通过 定时任务 来触发（一天更新一次、一个月更新一次......），具体的：

a）完成统计热词的过程.

b）根据热词，找到搜索结果的数据.

c）把得到缓存数据同步到缓存服务器上.

d）控制这些缓存服务器自动重启.

> 定期生成的优缺点

优点：实现起来比较简单，过程可控（缓存中有什么东西，是比较固定的），方便排查问题.

缺点：实时性不够，如果出现一些突发性的事件，出现了一些新的热点词，新的热词就可能对数据库带来较大的压力（缓存中查询没有，直接打到数据库），例如，过年的前几天，“春节晚会” 这个词就会变的特别高频、或者是某个突发的新闻......

#### 1.3.2、实时生成 ####

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

接着，之后用户每次查询：

*  如果在 Redis 中查到了，就直接返回.
 *  如果 Redis 中没有，就从数据库查询，在把查到的结果写入 Redis.

经过一段时间的 “动态平衡” ，redis 中的 key 就逐渐变成了 热点数据.

> 但是这样不停的写，redis 中的数据就会越来越多，达到 redis 配置的容量上限之后怎么办？

##### 内存淘汰策略（经典面试） #####

为了解决上述问题，就可以使用以下四种 “内存淘汰策略” （以下淘汰策略不局限于 redis）：

###### 1. FIFO (First In First Out) ：先进先出 ######

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

###### 2. LRU (Least Recently Used) ：淘汰最久未使⽤的 ######

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

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

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

###### 4. Random 随机淘汰 ######

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

##### 深入理解淘汰策略： #####

*假如在 甄嬛传 中，你是那个皇上，后宫佳丽三千，但实际上，你能宠幸的妃子也就那么几个（精力有限），相当于热点数据.*

*今天选秀一批新的小主，而你看上了其中的一个，那么就意味着后宫必有人失宠，那么到底要冷落谁呢？*

FIFO：皇后最老，先冷落了.

LRU：找个太监统计最近的宠幸时间，比如，皇后(10天前)、华妃（一个月前）、熹妃（一天前），那么华妃失宠.

LFU：找个太监统计最近的宠幸次数，比如，皇后（6次）、华妃（1次）、熹妃（10次），那么华妃失宠.

Random：随机冷落一个妃子.

##### redis 中采用的淘汰策略 #####

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

### 1.4、缓存使用的注意事项（重点） ###

#### 1.4.1、缓存预热（Cache preheating） ####

这里主要针对缓存更新策略是 实时生成的（定期生成 不涉及 “预热” ）.

> 为什么要预热？

redis 服务器首次接入之后，服务器是没有数据的，此时所有请求都会直接打给 mysql，在 redis 上没查到，而在 mysql 上查到的数据会继续写入 redis，随着时间推移，redis 上的数据越积累越多 mysql 承担的压力才逐渐变小 .

那么没预热前，mysql 的压力是相当大的.

> 如何解决上述问题？

通过缓存预热，就可以解决. 主要就是，把缓存 定期生成 和 实时生成 结合一下.

具体的，先通过离线的方式，通过一些统计途径，统计一些热点数据，导入到 redis 中，此时导入的这批热点数据，就能帮 mysql 承担很大压力了.

随着时间的推移，逐渐就使用新的热点数据淘汰旧数据了.

#### 1.4.2、缓存穿透（Cache penetration） ####

查询某个 key ，在 redis 中没有，mysql 中也没有，这个 key 也就不会更新到 redis 中。

这就导致，这次查询没有，下次查，还是没有....... 如果这样的数据很多，并且反复查询，一样会给 mysql 带来很大压力.

> 如何处理？

首先是一种亡羊补牢的方式：通过改进业务/加强监控警报，但这都是出现事故，才采取的行为.

更靠谱的方案（降低问题的严重性）：

1. 如果这个 key 在 redis 和 mysql 上都不存在，仍然把这个 key 写入 redis，value 设置成一个非法值，比如 "".

2. 引入布隆过滤器. 每次查询 redis / mysql 之前都先判定一下 key 是否在 布隆过滤器 上存在（布隆过滤器本质上是结合 hash + bitmap 实现的，以比较小的空间开销和比较快的速度，针对 key 是否存在进行判定），不存在就没必要查了.

#### 1.4.3、缓存雪崩（Cache avalanche） ####

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

> redis 上为什么会出现 大规模的 key 失效？

1. redis 直接挂了，比如 redis 宕机，或者 redis 集群模式下大量节点宕机.

2. redis 好着呢，但是可能之前短时间内设置了很多相同过期时间的 key.

> 如何处理？

1) 加强监控警报，例如采取集群的监控，或者哨兵监控的方式，加强 redis 集群可用性.

2）不给 key 设置过期时间，或者设置过期时间的时候，添加一些随机因子，来避免同时过期.

#### 1.4.4、缓存击穿（Cache breakdown） ####

这里翻译成 “击穿” 实际上不太合适，以至于一些面试官也分不清击穿和穿透（这种情况，最好两种都说明一下）.

这里更适合的翻译成 “瘫痪”.

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

> 如何处理？

1. 基于统计的方式发现热点 key，设置为永不过期. 这种方式往往需要服务器结构做出比较大的调整.

2. 进行必要的服务降级（例如服务器的功能本来有 10 个，特定情况下，会关闭一些不重要的功能，只保留核心功能. 类似于手机的省电模式），例如访问数据库的时候使用分布式锁，限制数据库的访问频率.

![ce2804b2507d4e22aeb5e988da906dfd.gif][]

[d056707ee89a4f6cbd182a27ff96d3e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/e4ca5f4717fe4a0681a3c79222ea493b.png
[ce2804b2507d4e22aeb5e988da906dfd.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/8ccdc2d71fab49b18a715c98950e87d4.png