技术分享 | Redis 持久化之 RDB 与 AOF

作者：贲绍华

爱可生研发中心工程师，负责项目的需求与维护工作。其他身份：柯基铲屎官。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

一、RDB（Redis Database）简介

RDB持久化方式能够在指定的时间间隔内（N秒内有M次改动时），对实例的数据进行快照存储，也就是全备的意思。

二、RDB - 特性

2.1 优点

• 单一文件，方便传输，适合灾备；
• 恢复大数据集时效率会比AOF快一些；
• 备份时会由fork出的子进程操作，父进程不需要其他IO操作，性能相对AOF来说占优。

2.2 缺点

• 在间隔其间发生意外宕机，会造成数据大量丢失；
• 数据量非常大时fork子进程非常耗时，可能会影响业务正常响应。

三、RDB - 策略

RDB的备份触发方式有两种类型，五种触发条件，分别为：

3.1 自动触发

• 根据conf内配置的save规则进行保存；
• 执行FLUSHALL（删除所有数据库里面的所有数据）命令会触发；
• 主动退出Redis会触发。

3.2 手动触发

• SAVE「同步执行」（保存数据至磁盘）；
• BGSAVE「异步执行」（保存数据至磁盘）。

3.3 操作流程

1.fork一个子进程,创建子进程时并不会发生数据复制，提高了复制速度降低了所需空间大小（内核级的系统调用:fork()）；

2.子进程获得所有数据指向地址的指针；

3.此时如有数据继续增加则触发写时复制，父进程指向新值地址，子进程依旧指向原值地址（COW（copy-on-write 写时复制））；

4.将指针指向的值写入备份；

5.备份完成。

四、RDB - 配置

五、RDB - 其他

5.1 时点性

当Redis在指定时间点触发全备时如果此后数据库依然有修改，则值还是会保留在未修改前的时间点，这样保证了不会发生时点混乱。

5.2 阈值建议

建议Redis使用内存控制在10-15G以内，过大的话会影响RDB落盘的速度。

5.3 RDB文件损坏该怎么办

在Redis的安装目录内，提供了redis-check-rdb工具用于对损坏的备份文件进行修复。

六、AOF（Append Only File）简介

AOF持久化方式即增备，记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行重写压缩，使得AOF文件的体积不至于过大。

6.1 AOF文件协议

下面列举一段AOF文件内容进行说明：

# 假设此时客户端执行了语句SET KEY VALUE，则AOF内容如下
*3
$3
SET
$3
KEY
$5
VALUE

上述内容中，看似比较杂乱，但理解一下其实很简单

*表示跳过$行时，往下一次读几行

$表示下一行有多少个字符

七、AOF - 特性

7.1 优点

• 异常宕机损失较小，能够做到数据不丢失或最多丢失1秒

7.2 缺点

• 对比RDB在恢复数据的效率上表现不高
• AOF文件会比RDB文件更大
• 根据所使用的 fsync 策略不同，AOF 的速度可能会慢于 RDB

八、AOF - 策略

AOF同样分为两种触发方式，根据配置项appendfsync（AOF持久化策略）的不同对应的执行时机也不同：

8.1 自动触发

• no（从不 fsync，buffer写满了就落盘，速度快）
• everysec「默认」（每一秒保存一次）
• always（每次都fsync，速度慢，可靠性高）

8.2 手动触发

BGREWRITEAOF「异步执行」（重写AOF文件）

九、AOF - 配置

十、AOF - 其他

10.1 AOF重写的版本差异性

• 4.0之前：删除可以相互抵消的命令，合并重复命令
• 4.0之后：先将内存数据都数据成RDB，后续操作依旧记录成AOF

10.2 AOF文件损坏了该怎么办

由于是增备，在数据持续写入时遇到意外宕机时很容易造成AOF文件的损坏，此时重启Redis实例会无法载入该文件。

解决的方式如下：

1.定时备份AOF文件

2.在Redis的安装目录中，提供了redis-check-aof工具用于修复异常的AOF文件，可以在修复完成后diff -u来对比一下修复前后文件的差异性