【Redis-面试题及持久化方案】Redis相关面试题（缓存穿透、缓存击穿、缓存雪崩） & Redis两种持久化方案详情对比（RDB、AOF）

缺乏、安全感 2023-10-09 17:29 2阅读 0赞

#### 【Redis-面试题及持久化方案】Redis相关面试题（缓存穿透、缓存击穿、缓存雪崩） & Redis两种持久化方案详情对比（RDB、AOF） ####

*  1）Redis 面试题
 *   *  1.1.高频面试题：缓存穿透、缓存击穿、缓存雪崩
     *  1.2.低频面试题：有关 redis 集群的面试题
 *  2）Redis 的持久化
 *   *  2.1.RDB 的持久化方案
     *   *  2.1.1.介绍
         *  2.1.2.RDB方案优点
         *  2.1.3.RDB方案缺点
         *  2.1.4.RDB配置
     *  2.2.AOF的持久化方案
     *   *  1.1.1.介绍
         *  1.1.2.开启AOF
         *  1.1.3.配置AOF
         *  1.1.4.AOF rewrite
         *  1.1.5.AOF优点
         *  1.1.6.AOF的缺点
     *  2.3.RDB or AOF

## 1）Redis 面试题 ##

### 1.1.高频面试题：缓存穿透、缓存击穿、缓存雪崩 ###

![在这里插入图片描述][a07e99325080459fa0c359c87f3af431.png]

### 1.2.低频面试题：有关 redis 集群的面试题 ###

从 Redis 3.0 发布提供 Redis Cluster 以后，经历 Redis 4.x、Redis5.x 和 Redis 6.x 一系列版本，Redis Cluster 更加成熟、稳定，推荐企业使用此种架构，通常公司也是使用此种架构。如果使用 Redis Cluster 集群，面试中碰到的问题有一些坑，还望注意。

*  问题一：Redis 的多数据库机制，了解多少？
    
    ![在这里插入图片描述][89cb62cc35254216bcd4760f32f2e6a1.png]
 *  问题二：懂 Redis 的批量操作么？
    
    ![在这里插入图片描述][8d888f1f13f241cfb9d7a56ec66eb080.png]
 *  问题三：Redis 集群机制中，你觉得有什么不足的地方吗？
    
    ![在这里插入图片描述][1cc65220c4c44f259229387a01a1d919.png]
 *  问题四：在 Redis 集群模式下，如何进行批量操作？
    
    ![在这里插入图片描述][ed0b702087c842a0b206c27dbf75ed87.png]
 *  问题五：懂 Redis 事务么？
    
    ![在这里插入图片描述][e02e7a925e674b02992f0d31dbcf102d.png]

## 2）Redis 的持久化 ##

### 2.1.RDB 的持久化方案 ###

#### 2.1.1.介绍 ####

Redis 会定期保存数据快照至一个 rbd 文件中，并在启动时自动加载 rdb 文件，恢复之前保存的数据。可以在配置文件中配置 Redis 进行快照保存的时机：

save [seconds] [changes]

意为在seconds秒内如果发生了changes次数据修改，则进行一次RDB快照保存，例如：

save 60 100

会让 Redis 每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行 RDB 快照保存。可以配置多条 save 指令，让 Redis 执行多级的快照保存策略。Redis 默认开启 RDB 快照。也可以通过 SAVE 或者 BGSAVE 命令手动触发 RDB 快照保存。SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：

*  SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
 *  BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在 BGSAVE 执行期间仍然可以继续处理客户端的请求。

#### 2.1.2.RDB方案优点 ####

1、对性能影响最小。如前文所述，Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。

2、每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。

3、使用RDB文件进行数据恢复比使用AOF要快很多。

#### 2.1.3.RDB方案缺点 ####

1、快照是定期生成的，所以在 Redis crash 时或多或少会丢失一部分数据。

2、如果数据集非常大且 CPU 不够强（比如单核 CPU），Redis 在 fork 子进程时可能会消耗相对较长的时间，影响 Redis 对外提供服务的能力。

#### 2.1.4.RDB配置 ####

**（1）修改redis的配置文件**

cd /export/server/redis-3.2.8/conf
    vim redis.conf
    # 第202行
    save 900 1
    save 300 10
    save 60 10000
    save 5 1

这三个选项是redis的配置文件默认自带的存储机制。表示每隔多少秒，有多少个key发生变化就生成一份 dump.rdb 文件，作为 redis 的快照文件。

例如：

save 60 10000 表示在60秒内，有10000个key发生变化，就会生成一份redis的快照。

**（2）重新启动redis服务**

每次生成新的 dump.rdb 都会覆盖掉之前的老的快照

ps -ef | grep redis
    bin/redis-cli -h node1.itcast.cn shutdown
    bin/redis-server redis.conf

### 2.2.AOF的持久化方案 ###

#### 1.1.1.介绍 ####

采用 AOF 持久方式时，Redis 会把每一个写请求都记录在一个日志文件里。在 Redis 重启时，会把 AOF 文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。

#### 1.1.2.开启AOF ####

AOF 默认是关闭的，如要开启，进行如下配置：

# 第594行
    appendonly yes

#### 1.1.3.配置AOF ####

AOF提供了三种fsync配置：

`always/everysec/no`（通过配置项\[appendfsync\]指定）

*  `appendfsync no`：不进行fsync，将flush文件的时机交给OS决定，速度最快
 *  `appendfsync always`：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
 *  `appendfsync everysec`：折中的做法，交由后台线程每秒fsync一次

#### 1.1.4.AOF rewrite ####

随着 AOF 不断地记录写操作日志，因为所有的写操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让 AOF 文件过大，也会让数据恢复的时间过长。不过 Redis 提供了 AOF rewrite 功能，可以重写 AOF 文件，只保留能够把数据恢复到最新状态的最小写操作集。

AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：

auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

*  Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite
 *  auto-aof-rewrite-min-size最开始的AOF文件必须要触发这个文件才触发，后面的每次重写就不会根据这个变量了。该变量仅初始化启动Redis有效

#### 1.1.5.AOF优点 ####

1、最安全，在启用 appendfsync 为 always 时，任何已写入的数据都不会丢失，使用在启用 appendfsync everysec 也至多只会丢失1秒的数据。

2、AOF 文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用 redis-check-aof 工具轻松修复。

3、AOF 文件易读，可修改，在进行某些错误的数据清除操作后，只要 AOF 文件没有 rewrite，就可以把 AOF 文件备份出来，把错误的命令删除，然后恢复数据。

#### 1.1.6.AOF的缺点 ####

1、AOF 文件通常比 RDB 文件更大。

2、性能消耗比 RDB 高。

3、数据恢复速度比 RDB 慢。

Redis的数据持久化工作本身就会带来延迟，需要根据数据的安全级别和性能要求制定合理的持久化策略：

*  AOF + fsync always 的设置虽然能够绝对确保数据安全，但每个操作都会触发一次 fsync，会对 Redis 的性能有比较明显的影响
 *  AOF + fsync every second 是比较好的折中方案，每秒 fsync 一次
 *  AOF + fsync never 会提供 AOF 持久化方案下的最优性能

使用RDB持久化通常会提供比使用AOF更高的性能，但需要注意RDB的策略配置。

### 2.3.RDB or AOF ###

每一次 RDB 快照和 AOF Rewrite 都需要 Redis 主进程进行 fork 操作。fork 操作本身可能会产生较高的耗时，与 CPU 和 Redis 占用的内存大小有关。根据具体的情况合理配置 RDB 快照和 AOF Rewrite 时机，避免过于频繁的 fork 带来的延迟。

[a07e99325080459fa0c359c87f3af431.png]: https://img-blog.csdnimg.cn/a07e99325080459fa0c359c87f3af431.png
[89cb62cc35254216bcd4760f32f2e6a1.png]: https://img-blog.csdnimg.cn/89cb62cc35254216bcd4760f32f2e6a1.png
[8d888f1f13f241cfb9d7a56ec66eb080.png]: https://img-blog.csdnimg.cn/8d888f1f13f241cfb9d7a56ec66eb080.png
[1cc65220c4c44f259229387a01a1d919.png]: https://img-blog.csdnimg.cn/1cc65220c4c44f259229387a01a1d919.png
[ed0b702087c842a0b206c27dbf75ed87.png]: https://img-blog.csdnimg.cn/ed0b702087c842a0b206c27dbf75ed87.png
[e02e7a925e674b02992f0d31dbcf102d.png]: https://img-blog.csdnimg.cn/e02e7a925e674b02992f0d31dbcf102d.png