Redis 持久化

持久化能有效地避免因进程退出造成数据丢失问题， 当下次重启时利用之前持久化的文件即可实现数据恢复。Redis 支持 RDB 和 AOF 两种持久化机制。

RDB持久化

RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，触发 RDB 持久化过程分为手动触发和自动触发。

RDB触发机制

手动触发

手动触发分别对应 save 和 bgsave 命令：

• save 命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例造成长时间阻塞，基本不采用。
• bgsave 命令：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。

Redis 内部的所有涉及 RDB 的操作都采用类似 bgsave 的方式。

bgsave 是主流的 RDB 持久化方式，下图是它的运作流程。

bgsave 命令的运作流程

1. 执行 bgsave 命令，Redis 父进程判断当前进是否存在其他正在执行的子进程，如 RDB/AOF 子进 程，如果存在 bgsave 命令直接返回。
2. 父进程执行 fork 创建子进程，fork 过程中父进程会阻塞，通过 info stats 命令查看 latest_fork_usec 选项，可以获取最近⼀次 fork 操作的耗时，单位为微秒。
3. 父进程 fork 完成后，bgsave 命令返回 “Background saving started” 信息并不再阻塞父进程，可以继续响应其他命令。
4. 子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后⼀次生成 RDB 的时间，对应 info 统计的 rdb_last_save_time 选项。
5. 进程发送信号给父进程表示完成，父进程更新统计信息。

自动触发

在以下的情况，Redis 会自动触发 RDB 持久化机制

1. 使用 save 配置。如 “save m n” 表示 m 秒内数据集发生了 n 次修改，自动 RDB 持久化。
2. 从节点进行全量复制操作时，主节点自动进行 RDB 持久化，随后将 RDB 文件内容发送给从结点。
3. 执行 shutdown 命令关闭 Redis 时，执行 RDB 持久化。

RDB文件的处理

保存：RDB 文件保存再 dir 配置指定的目录（默认 /var/lib/redis/）下，文件名通过 dbfilename 配置（默认 dump.rdb）指定。可以通过执行 config set dir {newDir} 和 config set dbfilename {newFilename} 运行期间动态执行，当下次运行时 RDB 文件会保存到新目录。

压缩：Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数 config set rdbcompression {yes|no} 动态修改。

虽然压缩 RDB 会消耗 CPU，但可以大幅降低文件的体积，方便保存到硬盘或通过网络发送到从节点，因此建议开启。

校验：如果 Redis 启动时加载到损坏的 RDB 文件会拒绝启动。这时可以使使用 Redis 提供的 redischeck-dump 工具检测 RDB 文件并获取对应的错误报告。

RDB 的优缺点

• RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行 bgsave 备份，并把 RDB 文件复制到远程机器或者文件系统中(如 hdfs) 用于灾备。
• Redis 加载 RDB 恢复数据远远快于 AOF 的方式。
• RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 创建子进程，属于重量级操作，频繁执行成本过高。
• RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个 RDB 版本，兼容性可能有风险。

AOF持久化

AOF（Append Only File）持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能非常有帮助。

使用AOF

开启 AOF 功能需要在配置文件 redis.conf 设置配置：appendonly yes，默认不开启。AOF 文件名通过 appendfilename 配置（默认是 appendonly.aof）设置。保存目录同 RDB 持久化方式⼀致，通过 dir 配置指定。AOF 的工作流程操作：命令写入（append）、文件同步（sync）、文件重写 （rewrite）、重启加载（load）。

AOF工作流程

1. 所有的写入命令会追加到 aof_buf（缓冲区）中。
2. AOF 缓冲区根据对应的策略向硬盘做同步操作。
3. 随着 AOF 文件越来越⼤，需要定期对 AOF 文件进行重写，达到压缩的目的。
4. 当 Redis 服务器启动时，可以加载 AOF 文件进行数据恢复。

命令写入

AOF 命令写入的内容直接是文本协议格式。例如 set hello world 这条命令，在 AOF 缓冲区会追加如下文本：

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

此处遵守 Redis 格式协议，Redis 选择文本协议可能的原因：文本协议具备较好的兼容性；实现简单； 具备可读性。

AOF 过程中为什么需要 aof_buf 这个缓冲区？

Redis 使用单线程响应命令，如果每次写 AOF 文件都直接同步硬盘，性能从内存的读写变成 IO 读写，必然会下降。先写入缓冲区可以有效减少 IO 次数，同时，Redis 还可以提供多种缓冲区同步策略，让用户根据自己的需求做出合理的平衡。

文件同步

Redis 提供了多种 AOF 缓冲区同步文件策略，由参数 appendfsync 控制，不同值的含义如表所示。

AOF 缓冲区同步文件策略

可配置值	说明
always	命令写入 aof_buf 后调用 fsync 同步，完成后返回
everysec	命令写入 aof_buf 后只执行 write 操作，不进行 fsync。每秒由同步线程进行 fsync。
no	命令写入 aof_buf 后只执行 write 操作，由 OS 控制 fsync 频率。

系统调用 write 和 fsync 说明：

• write 操作会触发延迟写 (delayed write) 机制。Linux 在内核提供页缓冲区用来提供硬盘 IO 性能。write 操作在写入系统缓冲区后立即返回。同步硬盘操作依赖于系统调度机制，例如: 缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• Fsync 针对单个文件操作，做强制硬盘同步，fsync 将阻塞直到数据写入到硬盘。
• 配置为 always 时，每次写入都要同步 AOF 文件，性能很差，在一般的 SATA 硬盘上，只能支持大约几百 TPS 写入。除非是非常重要的数据，否则不建议配置。
• 配置为 no 时，由于操作系统同步策略不可控，虽然提高了性能，但数据丢失风险大增，除非数据重要程度很低，一般不建议配置。
• 配置为 everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能。理论上最多丢失1秒的数据。

重写机制

随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入 AOF 重写机制压缩文件体积。AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新的 AOF 文件。

重写后的 AOF 为什么可以变小？

• 进程内已超时的数据不再写入文件。
• 旧的 AOF 中的无效命令，例如 del、hdel、srem 等重写后将会删除，只需要保留数据的最终版本。
• 多条写操作合并为⼀条，例如 lpush list a、lpush list b、lpush list 从可以合并为 lpush list a b c。

较小的 AOF 文件一方面降低了硬盘空间占用，一方面可以提升启动 Redis 时数据恢复的速度。

AOF 重写过程可以手动触发和自动触发：

• 手动触发：调用 bgrewriteaof 命令。

• 自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。

  • auto-aof-rewrite-min-size：表示触发重写时 AOF 的最小文件大小，默认为 64MB。

  • auto-aof-rewrite-percentage：代表当前 AOF 占用大小相比较上次重写时增加的比例。

AOF 重写流程

1. 执行 AOF 重写请求。 如果当前进程正在执行 AOF 重写，请求不执行。如果当前进程正在执行 bgsave 操作，重写命令延迟到 bgsave 完成之后再执行。

2. 父进程执行 fork 创建子进程。

3. 重写

   a. 主进程 fork 之后，继续响应其他命令。所有修改操作写入 AOF 缓冲区并根据 appendfsync 策略同步到硬盘，保证旧 AOF 文件机制正确。

   b. 子进程只有 fork 之前的所有内存信息，父进程中需要将 fork 之后这段时间的修改操作写入 AOF 重写缓冲区中。

4. 子进程根据内存快照，将命令合并到新的 AOF 文件中。

5. 子进程完成重写

   a. 新文件写入后，子进程发送信号给父进程。

   b. 父进程把 AOF 重写缓冲区内临时保存的命令追加到新 AOF 文件中。

   c. 用新 AOF 文件替换老 AOF 文件。

启动时数据恢复

当 Redis 启动时，会根据 RDB 和 AOF 文件的内容，进行数据恢复，如图所示。

Redis 根据持久化文件进行数据恢复

总结

1. Redis 提供了两种持久化方案：RDB 和 AOF。
2. RDB 视为内存的快照，产生的内容更为紧凑，占用空间较小，恢复时速度更快。但产生 RDB 的开销较大，不适合进行实时持久化，一般用户冷备和主从复制。
3. AOF 视为对修改命令保存，在恢复时需要重放命令。并且有重写机制来定期压缩 AOF 文件。
4. RDB 和 AOF 都使用 fork 创建子进程，利用 Linux 子进程拥有父进程内存快照的特点进行持久化，尽可能不影响主进程继续处理后续命令。
   。但产生 RDB 的开销较大，不适合进行实时持久化，一般用户冷备和主从复制。
5. AOF 视为对修改命令保存，在恢复时需要重放命令。并且有重写机制来定期压缩 AOF 文件。
6. RDB 和 AOF 都使用 fork 创建子进程，利用 Linux 子进程拥有父进程内存快照的特点进行持久化，尽可能不影响主进程继续处理后续命令。