概述
Redis 官方提供了两种不同的持久化方法来将数据存储到硬盘，分别是：
- 快照（Snapshot）
- AOF（Append Only File）只追加日志文件
默认开启快照，同时启用两种持久化方式时，优先 AOF
快照（Snapshot）
这种方式可以将某一时刻的所有数据都写入硬盘，保存的文件以 .rdb 形式结尾的文件，因此也称 RDB 方式
1. 快照生成方式
1.1 客户端方式
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于：save 在「主进程」执行，有可能阻塞「主进程」，而 bgsave 会创建一个「子进程」执行
1.2 服务器配置
save 3600 1 300 100 60 10000
上述是 redis.conf 中的相关内容，需要注意的点有两个：
- 如果配置
save ""可以完全禁用快照 - redis 默认开启快照，并且默认配置如下：
save 3600 1 300 100 60 10000，它的意思是，只要满足下面条件的任意一个，就会执行bgsave- 3600 秒（1 小时）之内，对数据库进行了至少 1 次修改
- 300 秒（5 分钟）之内，对数据库进行了至少 100 次修改
- 60 秒之内，对数据库进行了至少 10000 次修改
如果我们要自定义快照生成频率，只需要按照模板修改就好了
2. 保存快照
# rdb快照文件名
dbfilename dump.rdb
# rdb快照文件存放目录,请确保有写权限
dir ./
3. 其他相关配置
# 默认使用bgsave持久化时,如果发生错误,将停止写RDB快照文件,用户有时很难意识到数据并没有正确的被持久化
# 如果你已经设置了对Redis服务的正确监控,可以考虑关闭该特性,允许忽略错误,继续写RDB快照文件
# yes:开启 no:关闭
stop-writes-on-bgsave-error yes
# 是否使用LZF压缩字符串对象,一般建议开启
# yes:开启 no:关闭
rdbcompression yes
# 在写入和读取RDB文件时是否检查有无损坏
# yes:开启 no:关闭
rdbchecksum yes
# 加载RDB或还原负载时,启用或禁用ziplist和listpack等完全消毒检查
# yes:检查 no:不检查 clients:只对用户连接执行检查
sanitize-dump-payload no
# 在未启用持久性的实例中删除复制使用的RDB文件,默认情况下此选项处于禁用状态
# 此项仅适用于同时禁用AOF和RDB持久性的实例,否则将完全忽略
rdb-del-sync-files no
4. bgsave 执行原理
当接收到 bgsave 命令时，redis 会调用 fork 创建一个子进程，子进程负责将快照写入磁盘，父进程则继续处理命令
父进程可以继续执行命令，也就是数据能被修改，关键在于使用了「写时复制技术」，通过 fork 创建的子进程，和父进程共享同一片内存数据，子进程会复制父进程的页表，但是页表指向的物理内存还是同一个，这是为了加快创建子进程的速度，所以，子进程可以直接读取主进程的内存数据，并写入 RDB 文件
当主进程对共享数据只是只读操作，那么子进程和父进程互不影响，但如果主进程要修改共享数据的某一项，就会发生写时复制，这块数据会被复制一份，然后主进程在该副本进行修改，子进程继续把原来的数据写入 RDB 文件，也就是说，主进程刚修改的数据，是没办法在这一时间写入 RDB 文件的，只能交由下一次的 bgsave 快照
5. 自动触发
除了上述的方式以外，以下情况也会自动生成快照：
- 主从复制时，从节点从主节点进行全量复制时会触发 bgsave 操作，生成当时的快照发送到从节点
- 执行 debug reload 命令重新加载 redis 时会触发 bgsave 操作
- 执行 shutdown 命令时，如果没有开启 aof 持久化，会触发 bgsave 操作
只追加日志文件（Append Only File）
这种方式可以将所有客户端执行的写命令记录到日志文件中，以此记录数据发生的变化。只要 Redis 从头到尾执行一次 AOF 文件所包含的所有写命令，就可以恢复 AOF 文件的记录的数据集
1. 触发 AOF 持久化
redis 默认配置没有开启 AOF 持久化机制，需要在 redis.conf 开启
# yes:开启AOF持久化 no:关闭AOF持久化
appendonly yes
# 指定生成AOF文件名称
appendfilename "appendonly.aof"
# 指定存储AOF文件的文件夹名称
appenddirname "appendonlydir"
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置
dir ./
从 Redis7 版本开始，使用一组 aof 文件记录数据，分为两种基本类型：
- 基本文件，表示文件创建时的完整的数据，可以是 rdb 或 aof 内容格式
- 增量文件，记录前一个文件之后的新增命令
- 清单文件，追踪文件的创建和使用顺序
文件名是以 appendfilename 前缀，后面跟着序号和类型，因此 aof 文件目录里生成的文件大概有：
- 基本文件 appendonly.aof.1.base.rdb
- 增量文件 appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof......
- 清单文件 appendonly.aof.manifest
2. 写回策略
Redis 是先执行写操作命令，再将该命令记录到 AOF 日志，只有写操作命令执行成功，才会进行记录，这两个操作都在主线程进行，都会占用磁盘 I/O，因此 AOF 日志写回磁盘的时机很重要
写回策略分为三种：
- always（谨慎使用）：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据
- everysec（默认）：每秒钟写入一次磁盘，最多丢失一秒的数据
- no（不推荐）：由操作系统决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘
配置项如下：
appendfsync everysec
至于这三种策略是如何实现的，其实只是在控制 fsync() 函数的调用时机
当应用程序向文件写入数据时，内核通常先将数据复制到内核缓冲区中，然后排入队列，然后由内核决定何时写入硬盘
如果想要应用程序向文件写入数据后，能立马将数据同步到硬盘，就可以调用 fsync() 函数，这样内核就会将内核缓冲区的数据直接写入到硬盘，等到硬盘写操作完成后，该函数才会返回
- Always 策略就是每次写入 AOF 文件数据后，就执行
fsync()函数 - Everysec 策略就会创建一个异步任务来执行
fsync()函数 - No 策略就是永不执行
fsync()函数
3. 重写 AOF 文件
AOF 持久化机制会记录每个写命令，因此 AOF 文件会越来越大，会影响数据恢复的效率。AOF 文件重写会将内存中的数据库内容用命令的方式重写一个新的 aof 文件，替换原有文件，减小 aof 文件体积
3.1 触发重写的方式
第一种方式：客户端执行 BGREWRITEAOF 命令触发重写，不会阻塞 redis 服务
第二种方式：在服务器配置自动触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
如上配置，启用 AOF 持久化后，当 AOF 文件体积大于 64 M，并且 AOF 文件体积比上次重写之后体积大了至少一倍时，会自动触发重写
指定百分比为 0 可以禁用自动 AOF 重写
auto-aof-rewrite-percentage 0
3.2 重写流程
- bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行
- 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞
- 子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失
- 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件
- 使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写
4. 其他配置
# 前面讲过,AOF是调用fsync()函数将写操作记录写回磁盘,这会占用一定的磁盘I/O
# 如果设为yes,相当于appendfsync no,不会执行写磁盘操作,只是写入缓冲区,缓解磁盘压力
no-appendfsync-on-rewrite no
# 在Redis启动过程中,当AOF数据重新加载回内存时,可能会发现AOF文件在最后被截断
# 如果设置为yes,则加载一个截断的AOF文件,并通过日志告诉用户该事件
# 如果设置为no,服务器将因错误而中止并拒绝启动,用户需要使用“redis-check-aof”实用程序修复AOF文件
aof-load-truncated yes
# 开启混合持久化,下面会提到
aof-use-rdb-preamble yes
# 支持在aof中记录时间戳,可以在特定时间恢复数据,但会改变aof格式,可能跟已经存在的aof文件不兼容
aof-timestamp-enabled no
RDB 和 AOF 混合方式
Redis4.0 提出了一个混合使用 AOF 日志和内存快照的方法，混合持久化同样也是通过 bgrewriteaof 重写命令完成的，不同的是，当开启混合持久化后，fork 出的子进程先将共享的内存副本全量的以 RDB 方式写入 aof 文件，然后在将重写缓冲区的增量命令以 AOF 方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件
配置如下：
aof-use-rdb-preamble yes
备份数据
备份 RDB 文件只需将其拷贝到安全的地方，服务器运行时复制 RDB 文件很安全，因为 RDB 文件一旦创建就不会修改了
备份 AOF 在 Redis7.0.0 之前也可直接拷贝，但 7.0.0 版本之后会在 aof 文件夹下有多个文件，在 aof 重写时拷贝可能会得到无法使用的文件，所以在备份时需要关闭 aof 重写，步骤：
- 关闭自动 aof 重写：
CONFIG SET auto-aof-rewrite-percentage 0 - 确保在此期间没有手动 BGREWRITEAOF 启动重写
- 检查是否正在重写，查询
INFO persistence，如果返回1，则要等待重写完成 - 将 aof 文件夹拷贝到安全地方
- 重新打开自动 aof 重写：
CONFIG SET auto-aof-rewrite-percentage <prev-value>
相关文章
