Redis 官方提供了两种不同的持久化方法来将数据存储到硬盘，分别是：

• 快照（Snapshot）

• AOF（Append Only File）只追加日志文件

默认开启快照，同时启用两种持久化方式时，优先 AOF

2|0快照（Snapshot）

这种方式可以将某一时刻的所有数据都写入硬盘，保存的文件以 .rdb 形式结尾的文件，因此也称 RDB 方式

1. 快照生成方式

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于：save 在「主进程」执行，有可能阻塞「主进程」，而 bgsave 会创建一个「子进程」执行

1.2 服务器配置

上述是 redis.conf 中的相关内容，需要注意的点有两个：

• 如果配置 save "" 可以完全禁用快照

• redis 默认开启快照，并且默认配置如下：save 3600 1 300 100 60 10000，它的意思是，只要满足下面条件的任意一个，就会执行 bgsave

• 3600 秒（1 小时）之内，对数据库进行了至少 1 次修改

• 300 秒（5 分钟）之内，对数据库进行了至少 100 次修改

• 60 秒之内，对数据库进行了至少 10000 次修改

如果我们要自定义快照生成频率，只需要按照模板修改就好了

2. 保存快照

当接收到 bgsave 命令时，redis 会调用 fork 创建一个子进程，子进程负责将快照写入磁盘，父进程则继续处理命令

父进程可以继续执行命令，也就是数据能被修改，关键在于使用了「写时复制技术」，通过 fork 创建的子进程，和父进程共享同一片内存数据，子进程会复制父进程的页表，但是页表指向的物理内存还是同一个，这是为了加快创建子进程的速度，所以，子进程可以直接读取主进程的内存数据，并写入 RDB 文件

当主进程对共享数据只是只读操作，那么子进程和父进程互不影响，但如果主进程要修改共享数据的某一项，就会发生写时复制，这块数据会被复制一份，然后主进程在该副本进行修改，子进程继续把原来的数据写入 RDB 文件，也就是说，主进程刚修改的数据，是没办法在这一时间写入 RDB 文件的，只能交由下一次的 bgsave 快照

5. 自动触发

除了上述的方式以外，以下情况也会自动生成快照：

• 主从复制时，从节点从主节点进行全量复制时会触发 bgsave 操作，生成当时的快照发送到从节点

• 执行 debug reload 命令重新加载 redis 时会触发 bgsave 操作

• 执行 shutdown 命令时，如果没有开启 aof 持久化，会触发 bgsave 操作

3|0只追加日志文件（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 100auto-aof-rewrite-min-size 64mb

如上配置，启用 AOF 持久化后，当 AOF 文件体积大于 64 M，并且 AOF 文件体积比上次重写之后体积大了至少一倍时，会自动触发重写

指定百分比为 0 可以禁用自动 AOF 重写

auto-aof-rewrite-percentage 0

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. 其他配置

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>

来源：https://www.cnblogs.com/Yee-Q/p/16573521.html