Redis - RDB与AOF持久化技术-编程知识

Redis 持久化技术

RDB 是默认持久化方式，但 Redis 允许 RDB 与 AOF 两种持久化技术同时

开启，此时系统会使用 AOF 方式做持久化，即 AOF 持久化技术的优先级要更高。同样的道

理，两种技术同时开启状态下，系统启动时若两种持久化文件同时存在，则优先加载 AOF

持久化文件。

RDB 持久化

RDB ， Redis DataBase ，是指将内存中某一时刻的数据快照全量写入到指定的 rdb 文件的

持久化技术。 RDB 持久化默认是开启的。当 Redis 启动时会自动读取 RDB 快照文件，将数据从硬盘载入到内存，以恢复 Redis 关机前的数据库状态。

RDB 持久化的执行有三种方式：手动 save 命令、手动 bgsave 命令，与自动条件触发。

手动 save 命令，手动 bgsave 命令

通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。 save 命令在执行期

间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server 进程阻塞期间， Redis

不能处理任何读写请求，无法对外提供服务。

通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命

令的是，正如该命令的名称一样， background save ，后台运行 save 。 bgsave 命令会使服务器

进程 redis-server 生成一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程

中，不会阻塞 redis-server 进程对客户端读写请求的处理。

自动条件触发

自动条件触发的本质仍是 bgsave 命令的执行。只不过是用户通过在配置文件中做相应

的设置后， Redis 会根据设置信息自动调用 bgsave 命令执行。

RDB 持久化过程

在进行持久化过程中，如果 redis-server 进程接收到了用户写请求，则系统会将

内存中发生数据修改的物理块 copy 出一个副本。等内存中的全量数据 copy 结束后，会再将

副本中的数据 copy 到 RDB 临时文件。这个副本的生成是由于 Linux 系统的写时复制技术

（ Copy-On-Write ）实现的

写时复制技术是 Linux 系统的一种进程管理技术。

原本在 Unix 系统中，当一个主进程通过 fork() 系统调用创建子进程后，内核进程会复制主进

程的整个内存空间中的数据，然后分配给子进程。这种方式存在的问题有以下几点：

 这个过程非常耗时

 这个过程降低了系统性能

 如果主进程修改了其内存数据，子进程副本中的数据是没有修改的。即出现了数据冗余，

而冗余数据最大的问题是数据一致性无法保证。

现代的 Linux 则采用了更为有效的方式：写时复制。子进程会继承父进程的所有资源，其中

就包括主进程的内存空间。即子进程与父进程共享内存。只要内存被共享，那么该内存就是

只读的（写保护的）。而写时复制则是在任何一方需要写入数据到共享内存时都会出现异常，

此时内核进程就会将需要写入的数据 copy 出一个副本写入到另外一块非共享内存区域。

AOF 持久化

AOF ， Append Only File ，是指 Redis 将每一次的写操作都以日志的形式记录到一个 AOF

文件中的持久化技术。当需要恢复内存数据时，将这些写操作重新执行一次，便会恢复到之

前的内存数据状态。

默认情况下 AOF 持久化是没有开启的，通过修改配置文件中的 appendonly 属性为 yes

可以开启。

Redis 7 发生了重大变化。原来只有一个 appendonly.aof 文件，现在具有了三类多个

文件：

 基本文件：可以是 RDF 格式也可以是 AOF 格式。其存放的内容是由 RDB 转为 AOF 当

时内存的快照数据。该文件可以有多个。

 增量文件：以操作日志形式记录转为 AOF 后的写入操作。该文件可以有多个。

 清单文件：用于维护 AOF 文件的创建顺序，保障激活时的应用顺序。该文件只有一个。