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

news2024/11/25 15:48:14

【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.高频面试题：缓存穿透、缓存击穿、缓存血崩

在这里插入图片描述

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

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

问题一：Redis 的多数据库机制，了解多少？
问题二：懂 Redis 的批量操作么？
问题三：Redis 集群机制中，你觉得有什么不足的地方吗？
问题四：在 Redis 集群模式下，如何进行批量操作？
问题五：懂 Redis 事务么？

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有效