Redis设计与实现2.2：数据持久化

数据持久化

这是《Redis设计与实现》系列的文章，系列导航：Redis设计与实现笔记

RDB持久化

RDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成 RDB 文件时的数据库状态。

基本使用

另外，由于AOF文件更新更频繁，所以：

• 优先使用AOF进行还原

• 只有AOF关闭时才会进行RDB备份

• BGSAVE 虽然是非阻塞的，但是在进行时会拒绝掉 SAVE、BGSAVE命令，BGREWRITEAOF 会被推迟到执行完再执行。

• 而如果 BGREWRITEAOF 正在执行，则 BGSAVE 会被拒绝。

自动保存功能

设置

save 900 1
save 300 10

只要满足如下条件的一个，BGSAVE就会被执行：

• 900s内，对数据库至少进行了1次修改
• 300s内，对数据库至少进行了10次修改

原理

上述的配置信息保存的结构如下图所示：1

另外，程序还需要记录对应这两个配置在数据库中对应的信息：

• dirty计数器：记录距离上一次成功执行 SAVE 命令或者 BGSAVE 命令之后，服务器对数据库状态进行了多少次修改
• lastsave：记录上一次成功执行备份的UNIX时间戳

Redis服务器周期性操作函数 serverCron 默认每 100 毫秒执行一次，用于对正在运行的服务器进行维护，其中一项工作就是检查 save 选项保存的条件是否满足。

RDB文件结构

这里只给出了一个简单的关系图，如果想要了解具体的内容请阅读原书。

AOF持久化

AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库的状态的。

写入AOF的步骤

三步骤：

1. 命令追加：服务器执行完一个写命令后，会追加到服务器状态的 aof_buf 缓冲区的末尾
2. 文件写入：serverCron 函数在定时运行的时候会调用 flushAppendOnlyFile 函数，考虑是否将上述缓冲区的内容写入和保存到 AOF 文件中
3. 文件同步

写入和同步：

为了提高文件的写入效率，在现代操作系统中，当用户调用 write 函数时会先将数据保存在一个内存缓冲区里，等超过一定的时限或空间被填满再写入磁盘。

这样虽然提高了效率，但是可能会影响安全性。

为此，系统提供了 fsync 和 fdatasync 可以强制让操作系统立刻同步到硬盘中。

appendfsync 参数配置：

1. always：总是写入并同步
2. everysec：每秒进行写入并同步
3. no：写入但不同步

载入AOF的步骤

（很直观的步骤）

1. 创建一个不带网络连接的伪客户端
2. 从AOF文件中分析并读取一条写命令
3. 使用伪客户端执行该命令
4. 重复上述步骤，直到所有命令完成

AOF 重写

为什么？

由于 AOF 时通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF 文件的内容会越来越多，文件体积也会越来越大，需要加以控制，以免对 Redis 服务器、甚至整个宿主机造成影响。

怎么做？

BGREWRITEAOF 命令进行 AOF 重写。

重写的实现？

最简单的方法是通过分析 Redis 中的数据，然后生成相应的插入指令，而不是通过分析之前的命令来判断哪些可以被跳过。

后台重写

为了在重写过程中也能处理请求，可以采用后台重写的方式。当然在重写的过程中数据也可能发生变化，所以要设置一个 AOF 重写缓冲区。（类似主从复制时的操作）

当子进程完成 AOF 重写工作后，他会向父进程发送一个信号，父进程在接到该信号之后，就会调用一个信号处理函数（阻塞），并执行如下工作：

1. 将 AOF 重写缓冲区的内容写入到新的 AOF 文件中
2. 对新的 AOF 文件进行改名，原子地覆盖现有的 AOF 文件