Redis 持久化机制

概述

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 文件记录数据，分为两种基本类型：

1. 基本文件，表示文件创建时的完整的数据，可以是 rdb 或 aof 内容格式
2. 增量文件，记录前一个文件之后的新增命令
3. 清单文件，追踪文件的创建和使用顺序

文件名是以 appendfilename 前缀，后面跟着序号和类型，因此 aof 文件目录里生成的文件大概有：

1. 基本文件 appendonly.aof.1.base.rdb
2. 增量文件 appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof......
3. 清单文件 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 重写流程

1. bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行
2. 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞
3. 子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失
4. 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件
5. 使用新的 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>