Redis面试题(一)

ゝ一世哀愁。 2022-10-06 09:49 139阅读 0赞

*  临近秋招，备战暑期实习，祝大家每天进步亿点点！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5MTk4MA_size_16_color_FFFFFF_t_70_pic_center]

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

## 1、Redis 是单线程还是多线程的？ ##

*  redis 4.0 之前，redis 是**完全单线程的**。
 *  redis 4.0 时，redis 引入了多线程，但是**额外的线程只是用于后台处理**，例如：删除对象，核心流程还是完全单线程的。（核心流程指的是 redis 正常处理客户端请求的流程，通常包括：接收命令、解析命令、执行命令、返回结果等。）
 *  redis 6.0 中，**多线程主要用于网络 I/O 阶段**，也就是接收命令和写回结果阶段，而在执行命令阶段，还是由单线程串行执行。

> 为什么 Redis 是单线程？

在 redis 6.0 之前，redis 的核心操作是单线程的。因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的大小或者网络带宽。

既然CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了，因为如果使用多线程的话会更复杂，同时需要引入上下文切换、加锁等等，会带来额外的性能消耗。

> Redis 为什么使用单进程、单线程也很快？

主要有以下几点：

1、Redis 基于内存的操作

2、Redis 使用了 I/O 多路复用模型，select、epoll 等，基于 reactor 模式开发了自己的网络事件处理器

3、单线程可以避免不必要的上下文切换和竞争条件，减少了这方面的性能消耗。

## 2、Redis 在项目中的使用场景 ##

缓存（核心）、分布式锁（set + lua 脚本）、排行榜（zset）、计数（incrby）、消息队列（stream）、地理位置（geo）、访客统计（hyperloglog）等。

## 3、Redis 常见的数据结构 ##

> 基础的5种：

*  **String**：字符串，最基础的数据类型。
 *  **List**：列表。
 *  **Hash**：哈希对象。
 *  **Set**：集合。
 *  **Sorted Set**：有序集合，Set 的基础上加了个分值。

> 高级的4种：

*  **HyperLogLog**：通常用于基数统计（例如，网站访客统计）。
 *  **Bitmap**：位图。
 *  **Stream**：主要用于消息队列，类似于 kafka，可以认为是 pub/sub 的改进版。提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。
 *  **Geo**：redis 3.2 版本的新特性。可以将用户给定的地理位置信息储存起来， 并对这些信息进行操作：获取2个位置的距离、根据给定地理位置坐标获取指定范围内的地理位置集合。

## 4、Redis 删除过期键的策略（缓存失效策略、数据过期策略） ##

*  **定时删除**：在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作。对内存最友好，对 CPU 时间最不友好。
 *  **惰性删除**：放任键过期不管，但是每次获取键时，都检査键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。对 CPU 时间最优化，对内存最不友好。
 *  **定期删除**：每隔一段时间，默认 `100ms`，程序就对数据库进行一次检査，删除里面的过期键。至 于要删除多少过期键，以及要检査多少个数据库，则由算法决定。前两种策略的折中，对 CPU 时间和内存的友好程度较平衡。

Redis 使用惰性删除和定期删除。

## 5、Redis 的内存淘汰（驱逐）策略 ##

当 redis 的**内存空间**（maxmemory 参数配置）**已经用满时**，redis 将根据配置的驱逐策略（maxmemory-policy 参数配置），进行相应的淘汰动作。

*  noeviction：默认策略，不淘汰任何 key，直接返回错误。
 *  allkeys-lru：在所有的 key 中，使用 LRU 算法淘汰部分 key。
 *  allkeys-lfu：在所有的 key 中，使用 LFU 算法淘汰部分 key，该算法于 Redis 4.0 新增。
 *  allkeys-random：在所有的 key 中，随机淘汰部分 key。
 *  volatile-lru：在设置了过期时间的 key 中，使用 LRU 算法淘汰部分 key。
 *  volatile-lfu：在设置了过期时间的 key 中，使用 LFU 算法淘汰部分 key，该算法于 Redis 4.0 新增。
 *  volatile-random：在设置了过期时间的 key 中，随机淘汰部分 key。
 *  volatile-ttl：在设置了过期时间的 key 中，挑选 TTL（time to live，剩余时间）短的 key 淘汰。

## 6、淘汰算法 ##

*  FIFO：First In First Out，**先进先出**。新访问的数据插入 FIFO 队列尾部，数据在 FIFO 队列中顺序移动，淘汰 FIFO 队列头部的数据。
 *  LRU：Least Recently Used，**最近最少使用**。判断最近被使用的时间，目前最远的数据优先被淘汰。
    
     *  **新数据插入到链表头部，每当缓存数据被访问，则将数据移到链表头部，当链表满的时候，将链表尾部的数据丢弃**。
 *  LFU：Least Frequently Used，**最不经常使用**。在一段时间内，数据被使用次数最少的，优先被淘汰。
    
     *  **把数据加入到链表中，按频次排序，一个数据被访问过，把它的频次+1，发生淘汰的时候，把频次低的淘汰掉**。

## 7、Redis 的持久化机制有哪几种，各自的实现原理和优缺点？ ##

> Redis 的持久化机制有：RDB、AOF、混合持久化（RDB+AOF，Redis 4.0 引入）。

### ① RDB ###

*  **描述**：类似于快照。在指定的时间间隔内将内存中的数据集快照写入磁盘，可以指定时间归档数据，但不能做到实时持久化，RDB 持久化功能生成的 RDB 文件是经过**压缩的二进制文件**。
 *  **命令**：有两个 Redis 命令可以用于生成 RDB 文件，一个是 SAVE，另一个是 BGSAVE。
 *  **开启**：使用 save point 配置，满足 save point 条件后会触发 BGSAVE 来存储一次快照，这边的 save point 检查就是在上文提到的 serverCron 中进行。

save point 格式：`save <seconds> <changes>`，含义是 Redis 如果在 seconds 秒内数据发生了 changes 次改变，就保存快照文件。例如 Redis 默认就配置了以下3个：

save 900 1 # 900秒内有1个key发生了变化，则触发保存RDB文件
    save 300 10 # 300秒内有10个key发生了变化，则触发保存RDB文件
    save 60 10000 # 60秒内有10000个key发生了变化，则触发保存RDB文件

*  **关闭**：1）注释掉所有save point 配置可以关闭 RDB 持久化。2）在所有 save point 配置后增加：save “”，该配置可以删除所有之前配置的 save point。

save ""

*  **SAVE**：生成 RDB 快照文件，但是会阻塞主进程，服务器将无法处理客户端发来的命令请求，所以通常不会直接使用该命令。
 *  **BGSAVE**：fork 子进程来生成 RDB 快照文件，阻塞只会发生在 fork 子进程的时候，之后主进程可以正常处理请求。

> **RDB 的优点：**

*  RDB 文件是是经过压缩的二进制文件，**占用空间很小**，它保存了 Redis 某个时间点的数据集，很适合用于做备份。
 *  RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
 *  RDB 可以**最大化 redis 的性能**。父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

> **RDB 的缺点**：

*  RDB 在服务器故障时容易造成数据的丢失。RDB 允许我们通过修改 save point 配置来控制持久化的频率。但是，因为 RDB 文件需要保存整个数据集的状态， 所以它是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失5分钟数据。
 *  RDB 保存时使用 fork 子进程进行数据的持久化，如果数据比较大的话，fork 可能会非常耗时，造成 Redis 停止处理服务 N 毫秒。如果数据集很大且 CPU 比较繁忙的时候，停止服务的时间甚至会到一秒。

### ② AOF ###

*  **描述**：以日志的形式记录服务器所处理的每一个写、删除操作（查询操作不会记录），**以文本的方式记录**，并在服务器启动时，通过重新执行这些命令来还原数据集。
 *  **开启**：AOF 持久化默认是关闭的，可以通过配置：appendonly yes 开启。
 *  **关闭**：使用配置 appendonly no 可以关闭 AOF 持久化。

> **AOF 的优点**：

*  AOF 比 RDB可靠，支持秒级持久化，就算发生故障停机，也最多只会丢失一秒钟的数据。
 *  当 AOF文件太大时，Redis 会自动在后台进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。

> **AOF 的缺点**：

*  对于相同的数据集，AOF 文件的大小一般会比 RDB 文件大。
 *  RDB 存储的是压缩二进制格式记录数据命令，AOF 是通过文本日志形式记录数据命令，所以采用 AOF 数据恢复比 RDB 慢。

### ③ 混合持久化 ###

*  **描述**：混合持久化并不是一种全新的持久化方式，而是对已有方式的优化。混合持久化只发生于 AOF 重写过程。使用了混合持久化，重写后的新 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。
 *  **优点**：结合 RDB 和 AOF 的优点, 更快的重写和恢复。

## 8、为什么需要 AOF 重写文件？ ##

*  AOF 持久化是通过保存被执行的写命令来记录数据库状态的，随着写入命令的不断增加，AOF 文件中的内容会越来越多，文件的体积也会越来越大。
 *  如果不加以控制，体积过大的 AOF 文件可能会对 Redis 服务器、甚至整个宿主机造成影响，并且 AOF 文件的体积越大，使用 AOF 文件来进行数据还原所需的时间就越多。

举个例子， 如果你对一个计数器调用了 100 次 `INCR` ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录。然而在实际上， 只使用一条 `SET` 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 引入了 AOF 重写：可以在不打断服务端处理请求的情况下， 对 AOF 文件进行重建（rebuild）。

## 9、介绍下 AOF 重写的过程、AOF 后台重写存在的问题、如何解决 AOF 后台重写存在的数据不一致问题 ##

> **AOF 后台重写存在的问题**：

AOF 后台重写使用子进程进行从写，解决了主进程阻塞的问题，但是仍然存在另一个问题：子进程在进行 AOF 重写期间，服务器主进程还需要继续处理命令请求，新的命令可能会对现有的数据库状态进行修改，从而使得当前的数据库状态和重写后的 AOF 文件保存的数据库状态不一致。

> **如何解决 AOF 后台重写存在的数据不一致问题**：

为了解决上述问题，Redis 引入了 AOF 重写缓冲区（aof\_rewrite\_buf\_blocks），这个缓冲区在服务器创建子进程之后开始使用，当 Redis 服务器执行完一个写命令之后，它会同时将这个写命令追加到 AOF 缓冲区和 AOF 重写缓冲区。

这样一来可以保证：

*  1、现有 AOF 文件的处理工作会如常进行。这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
 *  2、从创建子进程开始，也就是 AOF 重写开始，服务器执行的所有写命令会被记录到 AOF 重写缓冲区里面。

这样，当子进程完成 AOF 重写工作后，父进程会在 serverCron 中检测到子进程已经重写结束，则会执行以下工作：

*  1、将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中，这时新 AOF 文件所保存的数据库状态将和服务器当前的数据库状态一致。
 *  2、对新的 AOF 文件进行改名，原子的覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换。

之后，父进程就可以继续像往常一样接受命令请求了。

## 10、同时开启RDB和AOF，服务重启时如何加载 ##

简单来说，**如果同时启用了 AOF 和 RDB，Redis 重新启动时，会先使用 AOF 文件来重建数据集**，因为通常来说， AOF 的数据会更完整。

而在引入了混合持久化之后，使用 AOF 重建数据集时，会通过文件开头是否为“REDIS”来判断是否为混合持久化。

完整流程如下图所示：

![c1618be1f307ae6abe68549b5831ee7f.png_pic_center][]

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

> 文章参考：[全网最硬核 Redis 高频面试题解析（2021年最新版）][Redis _2021]

总结的面试题也挺费时间的，文章会不定时更新，有时候一天多更新几篇，如果帮助您复习巩固了知识点，还请三连支持一下，后续会亿点点的更新！

![在这里插入图片描述][20210522180031226.gif_pic_center]

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

为了帮助更多小白从零进阶 Java 工程师，从CSDN官方那边搞来了一套 《Java 工程师学习成长知识图谱》，尺寸 `870mm x 560mm`，展开后有一张办公桌大小，也可以折叠成一本书的尺寸，有兴趣的小伙伴可以了解一下，当然，不管怎样博主的文章一直都是免费的~  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5MTk4MA_size_16_color_FFFFFF_t_70_pic_center 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5MTk4MA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221005/b45fc6253da040ce82df1d0025d8dffd.png
[c1618be1f307ae6abe68549b5831ee7f.png_pic_center]: /images/20221005/f76ffca4056948ccb1a98679ab9101b7.png
[Redis _2021]: https://joonwhee.blog.csdn.net/article/details/116109674
[20210522180031226.gif_pic_center]: /images/20221005/e2e1bf6510c942cdbb1087cd8d07549d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5MTk4MA_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221005/bb7089de863b40cda0f6817770af1f26.png