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

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 带来的延迟。