对比 Redis 中 RDB 和 AOF 持久化

概念

Redis 是内存数据库，数据存储在内存中，一旦服务器进程退出，数据就丢失了，所以 Redis 需要想办法将存储在内存中的数据持久化到磁盘。

Redis 提供了两种持久化功能：

RDB (Redis Database)：生成 RDB 文件，保存的是 key-value 的形式。
AOF (Append Only File)：保存 Redis 执行过程中的写命令。

生成

RDB 的生成

SAVE 命令会阻塞 Redis 服务进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
BGSAVE 命令会派生出一个子进程，然后由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理命令请求。

如果两个 key 值的修改具有事务性，需要手动加事务，不然备份时可能会导致两个值不一致。

除了主动执行命令，我们还可以通过 save 选项设置多个保存条件，只要任意一个条件满足，服务器就会执行 BGSAVE 命令：

save 900 1

save 300 10

save 60 10000

那么只要满足以下三个条件中的任意一个，BGSAVE 命令就会被执行：

服务器在900秒之内，对数据库进行了至少1次修改。
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000次修改。

AOF 的生成

只要打开 AOF 持久化功能，服务器在执行完一个写命令后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

现代操作系统中，用户在写文件时，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区被填满，或者超过了指定时限之后，才真正将缓冲区中的数据写入磁盘。这就有可能导致缓冲区内的数据还未写入磁盘，计算机发生停机，导致数据丢失。

appendfsync 选项的值可以决定 AOF 持久化功能的效率和安全性：

always 每次都同步到磁盘，效率低，安全性高；
everysec 每隔一秒同步到磁盘，效率足够快，安全性高，只丢失一秒的数据；
no 由操作系统控制同步到磁盘的时机，速度最快，安全性最低。

AOF 的重写

因为 AOF 保存的是写命令，随着服务器的运行，同一个键值被操作的次数越多，单个键值就会产生多条写命令，AOF 文件就会越大，还原的时间就会越久。

为了解决 AOF 体积膨胀的问题，Redis 提供了 AOF 文件重写（rewrite）功能。

AOF 重写并不是对旧的 AOF 文件进行压缩。Redis 会从数据库中读出数据，生成对应的写命令，并写入新的 AOF 文件中，当新的 AOF 文件重写了所有数据的写命令，就可以替换掉旧 AOF 文件。

AOF 重写可以在后台进行，在重写过程中新产生的数据，会写入 AOF 重写缓冲区中，当重写结束再把缓冲区的写命令追加到新的 AOF 文件中即可。

载入

RDB 的载入

RDB 文件的载入工作是在服务器启动时自动执行的，所以 Redis 没有专门用于载入的命令。

因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，所以：

如果服务器启动了AOF 持久化功能，那么服务器会优先使用 AOF 文件来还原数据库状态。
只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。

AOF 的载入

AOF 中包含了所有的写命令，服务器只要读入并重新执行一遍AOF文件里保存的写命令，就可以还原服务器关闭前的状态。

Redis 读取 AOF 文件并还原数据库状态的详细步骤：

创建一个不带网络连接的伪客户端：因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接，所以用来还原数据的伪客户端不需要网络连接；
从 AOF 文件中分析并读取出一条写命令；
使用伪客户端执行读出的写命令；
循环执行步骤2和步骤3，直到 AOF 文件中的所有命令都被执行。

资料

Redis设计与实现-黄健宏-微信读书

本文首发于我的个人博客 https://chaohang.top

作者张小超

转载请注明出处

欢迎关注我的微信公众号【超超不会飞】，获取第一时间的更新。