Redis 面试题——持久化

参考：《Redis 设计与实现》

1.概述

1.1.Redis 的持久化功能是指什么？

因为 Redis 是内存数据库，它将自己的数据储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据也会消失不见。为了解决这个问题，Redis 提供了持久化功能，即将 Redis 内存中的数据保存到磁盘上，以保证数据在 Redis 服务器重启后不会丢失。

1.2.Redis 有哪些持久化机制？

Redis 提供了两种持久化机制：RDB (Redis DataBase) 持久化和 AOF (Append Only File) 持久化。

2.RDB

2.1.什么是 RDB 持久化？

RDB 是 Redis 的默认持久化机制，它可以在指定的时间间隔内，或在满足一定条件时将 Redis 内存中的数据快照保存到磁盘上，以生成 RDB 文件。RDB 文件是以 Redis 数据库的数据结构和状态为基础，以二进制格式保存在硬盘上。当 Redis 重启时，可以通过加载 RDB 文件将数据恢复到内存中。

2.2.Redis 中使用什么命令来生成 RDB 快照文件？

（1）Redis 提供了以下两个命令来生成 RDB 快照文件：

• save：该命令会阻塞 Redis 服务器，直到快照过程完成，期间不会处理其他客户端的请求。它会将当前数据库的数据保存到一个 RDB 文件中。
• bgsave：该命令会在后台执行快照过程，不会阻塞 Redis 服务器。它会创建一个子进程来执行 RDB 快照，并在子进程完成后继续处理其他客户端请求（默认选项）。bgsave 中的 bg 是指 background，即将数据快照操作放到后台执行，以确保 Redis 服务器不会停止响应其他命令请求。

（2）使用 save 命令会阻塞服务器，直到快照完成，适用于对服务器负载影响较小且可以容忍阻塞的情况。而 bgsave 命令则不会阻塞服务器，适用于对服务器负载有较高要求或不能容忍阻塞的情况。生成的 RDB 快照文件会保存在 Redis 服务器指定的路径下，通常是由配置文件中的 dir 选项指定的路径。文件名类似于 dump.rdb，并且会覆盖之前生成的快照文件。

2.3.如何在 Redis 的配置文件中对 RDB 进行配置？

（1）在 Redis 的配置文件 redis.conf 文件中，默认有 RDB 持久化配置：

save 900 1
save 300 10
save 60 10000

这些配置称为检查点。上面 3 个检查点的解释依次为：

• 每隔 900s，如果有至少 1 个 key 发生了变更，就生成一个新的 dump.rdb 文件，这个 dump.rdb 文件就是 redis 内存中完整的数据快照，也叫做 snapshotting。
• 每隔 300s，检查是否有 10 个key 发生了变更，如果有，则生成 dump.rdb 文件。
• 每隔 60s，检查是否有 10000个 key 发生了变更，如果有，则生成 dump.rdb 文件。

（2）可以配置多项检查点，也可以移除所有检查点，只需要如下配置即可：

save ""

2.4.✨RDB 持久化的工作流程是什么样的？

（1）RDB 是 Redis 中的一种持久化方式，用于将数据库中的数据保存到硬盘上。下面是 RDB 持久化的一般工作流程：

• 触发保存指令生成快照文件：RDB 持久化的过程可以通过手动触发或配置自动触发。手动触发可以使用 SAVE 或 BGSAVE 指令，而自动触发可以通过配置 Redis 的参数来实现，例如通过设置 save 配置项。
• 创建子进程：当保存指令被触发后，Redis 会创建一个子进程来执行实际的持久化操作。子进程的创建通常会通过 fork 系统调用，在子进程中执行持久化操作，而父进程则继续处理客户端请求。
• 写入数据：子进程开始执行持久化操作后，会遍历数据库中的所有键值对，并将数据写入到一个临时文件中。这个过程中，Redis 会将数据库的所有写操作都缓存到内存中，以保证数据的一致性。
• 写入完成后替换文件：当子进程将数据写入临时文件后，会通过一个原子操作，用临时文件替换掉原来的 RDB 文件。这样做可以保证在持久化过程中，其他客户端对数据的访问不受影响，只有在替换完成后，才会对外提供最新的 RDB 文件。
• 完成持久化：子进程完成文件替换后，会终止自身进程并返回结果给父进程。父进程会相应地更新相关的元数据，标识持久化操作已经完成。

（2）总的来说，RDB 持久化的工作流程是由触发指令、创建子进程、写入数据、替换和持久化完成这几个步骤组成。通过这个流程，Redis 可以将内存中的数据保存到硬盘上，实现数据的持久化和恢复。需要注意的是，RDB 持久化是一种快照方式，保存的是数据在某个时间点的状态，因此在进行恢复时，会使用最新的 RDB 文件进行加载。

AOF

3.1.什么是 AOF 持久化？

AOF 持久化是指在每次写操作时将操作记录追加到 AOF 文件末尾。这样，当 Redis 重启时，可以通过重新执行 AOF 文件中的操作来恢复 Redis 数据库中的数据。

3.2.✨AOF 工作基本流程是怎样的？如何开启 AOF？

（1）AOF 持久化功能的实现可以分为以下几步：

• 命令追加 (append)：服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾:
• 文件写入 (write)：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用 write 函数（系统调用），write 函数将数据写入到了系统内核缓冲区之后直接返回（延迟写）。需要注意的是，此时并没有同步到磁盘。
• 文件同步 (fsync)：AOF 缓冲区根据对应的持久化方式（fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
• 文件重写 (rewrite)：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩 AOF 文件的目的。
• 重启加载 (load)：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

（2）AOF 持久化配置默认是关闭的，所以需要手动开启，即在 Redis 配置文件 redis.conf 中添加如下配置即可：

appendonly yes

同理，如果上述配置为 appendonly no，则表示关闭 AOF 持久化。开启 AOF 持久化后就可以写入持久化文件 appendonly.aof 中，当然这个文件名字也是可以通过配置项 appendfilename 来设置的。

3.3.AOF 的持久化方式有哪几种？

（1）在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（即 appendfsync 选项的值），它们分别是：

（2）如果用户没有主动为 appendfsync 选项设置值，那么 appendfsync 选项的默认值为 everysec，其原因在于 everysec 兼顾了数据和写入性能。它让 Redis 每秒同步一次 AOF 文件，Redis 性能受到的影响较小。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会放慢自己的速度以便适应硬盘的最大写入速度。

3.4.AOF 持久化过程中为什么要使用缓冲区？可能会带来什么问题？

（1）为了提高文件的写入效率，在现代操作系统中，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

（2）这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。为此，系统提供了 fsync 和 fdatasync 两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

3.5.AOF 持久化的效率和安全性主要受什么因素影响？

（1）服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性:

• 当 appendfsync 的值为 always 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最慢的一个，但从安全性来说，always 也是最安全的，因为即使出现故障停机，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
• 当 appendfsync 的值为 everysec 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且每隔一秒就要在子线程中对AOF 文件进行一次同步。从效率上来讲，everysec 模式足够快，并且就算出现故障停机,数据库也只丢失一秒钟的命令数据。
• 当 appendfsync 的值为 no 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，至于何时对 AOF 文件进行同步，则由操作系统控制。因为处于 no 模式下的 flushAppendonlyFile 调用无须执行同步操作，所以该模式下的 AOF 文件写入速度总是最快的，不过因为这种模式会在系统缓存中积累一段时间的写入数据，所以该模式的单次同步时长通常是三种模式中时间最长的。

（2）从平摊操作的角度来看，no 模式和 everysec 模式的效率类似，当出现故障停机时，使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。

3.6.使用 AOF 持久化可能会带来什么问题？如何解决？

（1）如果使用 AOF 持久化，可能会带来以下两个问题：

• 因为 Redis 会不断地将被执行的写命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积也会不断增长，在极端情况下，体积不断增大的 AOF 文件甚至可能会用完硬盘的所有可用空间。
• 因为 Redis 在重启之后需要通过重新执行 AOF 文件记录的所有写命令来还原数据集，所以如果 AOF 文件的体积非常大，那么还原操作执行的时间就可能会非常长。

（2）为了解决 AOF 文件体积不断增大的问题，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会通过移除 AOF 文件中的冗余命令来重写 (rewrite) AOF 文件，使 AOF 文件的体积变得尽可能地小。BGREWRITEAOF 的工作原理和 BGSAVE 创建快照的工作原理非常相似：Redis 会创建一个子进程，然后由子进程负责对 AOF 文件进行重写。

注意：因为 AOF 文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在 AOF 持久化中也同样存在。更糟糕的是，如果不加以控制的话，AOF 文件的体积可能会比快照文件的体积大好几倍，在进行 AOF 重写并删除旧 AOF 文件的时候，删除一个体积达到数十 GB 大的旧 AOF 文件可能会导致操作系统挂起 (hang) 数秒。

（3）AOF 持久化也可以通过设置下面两个选项来自动执行 BGREWRITEAOF：

• auto-aof-rewrite-min-size：该值表示触发 AOF 重写的 AOF 文件最小值。如果 AOF 文件大小小于该值，则不会触发 AOF 重写，默认值为 64 MB；
• auto-aof-rewrite-percentage：该值表示当前 AOF 大小 aof_current_size 和上一次重写时 AOF 大小 aof_base_size 的比值。如果当前 AOF 文件大小增加了这个百分比值，将触发 AOF 重写。将此值设置为 0 将禁用自动 AOF 重写，默认值为 100；

举个例子，假设用户对 Redis 设置了配置选项 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb，并且启用了 AOF 持久化，那么当 AOF 文件的体积大于 64 MB，并且 AOF 文件的体积比上一次重与之后的体积大了至少一倍的时候，Redis 将执行 BGREWRITEAOF 命令。如果 AOF 重写执行得过于频繁的话，用户可以考虑将 auto-aof-rewrite-percentage 选项的值设置为 100 以上，这种做法可以让 Redis 在 AOF 文件的体积变得更大之后才执行重写操作，不过也会让 Redis 在启动时还原数据集所需的时间变得更长。

3.7.✨AOF 重写的具体过程是什么样的？

（1）AOF 是 Redis 里面的一种数据持久化方式，它采用了指令追加的方式，近乎实时地去实现数据指令的持久化，因为 AOF 持久化会把每个数据更改的操作指令，追加存储到 AOF 文件里面。所以很容易导致 AOF 文件出现过大，造成 I/O 性能问题。

（2）Redis 为了解决这个问题，设计了 AOF 重写机制，也就是说把 AOF 文件里面相同的指令进行压缩，只保留最新的数据指令。简单来说，如果 AOF 文件里面存储了某个 key 的多次变更记录，但是实际上，最终在做数据恢复的时候，只需要执行最新的指令操作就行了，历史的数据就没必要存在这个文件里面占空间。

（3）AOF 文件重写的具体过程分为以下几步：

• 首先，根据当前 Redis 内存里面的数据，重新构建一个新的 AOF 文件；
• 然后，读取当前 Redis 里面的数据，写入到新的 AOF 文件里面；
• 最后，重写完成以后，用新的 AOF 文件覆盖现有的 AOF 文件；

（4）在这个过程有三个需要注意的地方：

• 因为 AOF 在重写的过程中需要读取当前内存里面所有的键值数据，再生成对应的一条指令进行保存。而这个过程是比较耗时的，对业务会产生影响。所以 Redis 把重写的过程放在一个后台子进程里面来完成，这样一来，子进程在做重写的时候，主进程依然可以继续处理客户端请求。
• 为了避免子进程在重写过程中，主进程的数据发生变化，导致 AOF 文件和 Redis 内存中的数据不一致的问题，Redis 做了一层优化，即子进程在重写的过程中，主进程的数据变更需要追加到 AOF 重写缓冲区里面。等到 AOF 文件重写完成以后，再把 AOF 重写缓冲区里面的内容追加到新的 AOF 文件里面。
• 在进行 AOF 文件重写时，需要新建一个 AOF 文件，并将重写后的结果写入到该文件中，而不能直接在原 AOF 文件上进行操作，这样做的目的在于防止在重写过程中系统出现异常，从而导致在数据还原时原 AOF 文件中的出现数据不一致的情况。

3.8.✨AOF 文件的载入与数据还原的过程是什么样的？

（1）AOF 文件的载入于数据还原的过程如下：

• ① 创建一个不带网络连接的伪客户端 (fake client)：因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样。
• ② 从 AOF 文件中分析并读取出一条写命令。
• ③ 使用伪客户端执行被读出的写命令。
• ④ 一直执行步骤 ② 和步骤 ③，直到 AOF 文件中的所有写命令都被处理完毕为止。

（2）当完成以上步骤之后，AOF 文件所保存的数据库状态就会被完整地还原出来，整个过程如下图所示：

3.9.AOF 文件的校验机制是什么样的？

（1）Redis 的 AOF 持久化机制中，存在校验和 (checksum) 的校验机制，用于确保 AOF 文件内容的完整性。

（2）在 Redis 的 AOF 持久化过程中，每次写入操作完成后，Redis 都会计算校验和并将其附加到 AOF 文件的结尾。当 Redis 重新读取 AOF 文件时，它会根据文件内容计算校验和，并将其与 AOF 文件结尾附加的校验和进行比较。如果两者不相等，则意味着 AOF 文件已经被损坏或者篡改，Redis 将拒绝加载文件并退出。Redis 使用的校验和算法是 CRC64 校验和算法，这是一种广泛应用于数据传输和存储中的校验和算法，能够提供较高的校验精度并具有较高的执行效率。

（3）因为校验和机制的存在，Redis 的 AOF 文件具有较高的数据完整性和安全性，可以有效避免硬件故障、操作系统错误以及网络攻击等因素对 AOF 文件内容的破坏。在 Redis 的实际应用场景中，AOF 文件的校验机制为用户提供了一种有效的保护机制，帮助用户保障数据的安全和完整性。

4.RDB & AOF

4.1.✨RDB 和 AOF 这两种持久化方式有什么区别？如何选择合适的持久化方式？

（1）RDB 和 AOF 这两种持久化方式的区别如下所示：

（2）选择持久化方式的建议：

• Redis 保存的数据丢失一些也没什么影响的话，可以选择使用 RDB；
• 不建议单独使用 AOF，因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误；
• 如果保存的数据要求安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化；

4.2.AOF 文件和 RDB 文件可不可以同时存在？

AOF 和 RDB 是可以同时存在的，只不过需要注意以下几点：

• 同时生成了 RDB 和 AOF 文件，先使用 AOF 进行数据恢复。
• 如果 RDB 正在生成快照文件，而用户又在执行 AOF 重写命令，那么需要等到 RDB 快照生成之后，才会执行 AOF 重写。
• 如果 RDB 正在生成快照文件，那么 Redis 不会去执行 AOF 重写，相反也是。