RDB

RDB 持久化会把进程内的数据全量快照保存到硬盘上，其触发方式包括手动触发和自动触发。

手动触发

# 阻塞当前 Redis 服务器，直到 RDB dump 完成为止。内存里数据越大，阻塞时间越久。不建议在生产环境使用，未来会被废弃。
save

# fork 出一个子进程。子进程负责生成 RDB 文件后，通知父进程，主进程还可以继续响应其他命令。只有 fork 的一瞬间会阻塞 Redis 进程。
bgsave

bgsave 的工作流程如下：

bgsave 的工作流程

注意，RDB 文件本身永远只有一个。子进程产生的都是临时文件，会通过原子替换的方式来维持 RDB 文件的唯一性。

Redis 内部主动生成 RDB 文件的过程都是采用 bgsave 的方式。

自动触发

在 config 里配置save m n。表示 m 内数据集存在 n 次修改时，自动触发 bgsave。
如果从节点执行全量复制操作，主节点自动执行 bgsave生成 RDB 文件并发送给从节点。
执行 debug reload 命令重新加载 Redis 时，也自动触发 save 操作。
默认情况下执行 shutdown 命令时，如果没有开启 AOF 持久化功能，则自动执行 bgsave-Redis 自带的优雅关闭流程。

RDB 文件的存储

默认会存在 config set dir {newDir}和config set dbfilename {newFileName}的文件里。也可以动态修改（）比如在硬盘出问题的时候动态修改）。

默认情况下会对 RDB 文件进行 LZF 压缩处理（可以关闭）。压缩会消耗 CPU 性能，但利于网络传输。

RDB 的优缺点

优点：

紧凑存储，适于全量保存/恢复。
加载 RDB 的速度远快于 AOF 文件。

缺点：

没有办法强实时/秒级持久化。
版本不兼容

AOF（append only file）

以独立的日志（log）记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 具有持久化的强实时性，是 RDB 的补充。

配置方式

需要设置appendonly yes（默认不开启），开启后就会被自动触发（也就是说无需手动触发）。可以修改文件名和路径。

工作流程

aof 的工作流程如下：

此处输入图片的描述

其中：

append 其实是把写命令写入 aof_buf 中。
sync 是把写入命令从内存持久化到硬盘中。
rewrite 则会压缩重写 AOF 文件使其达到更紧凑的目的。
当 Redis 重启后，可以加载 AOF 文件进行数据恢复。

其中被持久化的命令，是纯文本的格式，遵循 RESP 协议。

文件同步

Redis 本身是个单线程架构，如果每次新的写命令都要写入硬盘，则硬盘的负载能力可能成为一个瓶颈。而如果先写入一个 aof_buf，则可以采取多种策略持久化数据到硬盘中。

这提醒我们，对于零散的多次写 IO，我们都要想办法化零为整，通过 buffer-sync 的分段异步写形式充分协调内存和硬盘的写性能。

我们可以采用的策略分别是：

always 命令写入 aof_buf 后调用系统 fsync 操作同步到 AOF 文件，fsync 完成后系统返回。等于一个强实时的策略。在 sata 上只有几百的 tps。
everysec 命令写入 aof_buf 后调用系统 write 操作，write 完成后线程返回。fsync 操作由专门线程每秒调用一次。等于一个中等实时的策略。默认策略，最多丢失 1s 的数据
no 命令写入 aof_buf后调用系统 write 操作，而不对 AOF 做 fsync 同步操作， fsync 同步操作由操作系统负责，通常同步周期最长 30 秒。无法保障同步实时性。

write 其实是一种 delaywrite，写入操作系统的页缓冲区以后线程会立即返回（阻塞期很短），依赖于系统的调度（如时间阈值满或者空间阈值满，期间如果系统宕机则数据会丢失）或者 fsync才能真正持久化到硬盘中。
fsync 就是强行同步到硬盘的syscall，阻塞时间会稍长，但持久化更彻底。