Redis 持久化机制

概述

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

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

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

快照（Snapshot）

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

1.1 客户端方式

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

1. 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. 保存快照

1. # rdb快照文件名
2. dbfilename dump.rdb
3. # rdb快照文件存放目录,请确保有写权限
4. dir ./

复制代码

3. 其他相关配置

1. # 默认使用bgsave持久化时,如果发生错误,将停止写RDB快照文件,用户有时很难意识到数据并没有正确的被持久化
2. # 如果你已经设置了对Redis服务的正确监控,可以考虑关闭该特性,允许忽略错误,继续写RDB快照文件
3. # yes:开启 no:关闭
4. stop-writes-on-bgsave-error yes
5. # 是否使用LZF压缩字符串对象,一般建议开启
6. # yes:开启 no:关闭
7. rdbcompression yes
8. # 在写入和读取RDB文件时是否检查有无损坏
9. # yes:开启 no:关闭
10. rdbchecksum yes
11. # 加载RDB或还原负载时,启用或禁用ziplist和listpack等完全消毒检查
12. # yes:检查 no:不检查 clients:只对用户连接执行检查
13. sanitize-dump-payload no
14. # 在未启用持久性的实例中删除复制使用的RDB文件,默认情况下此选项处于禁用状态
15. # 此项仅适用于同时禁用AOF和RDB持久性的实例,否则将完全忽略
16. 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 开启

1. # yes:开启AOF持久化 no:关闭AOF持久化
2. appendonly yes
3. # 指定生成AOF文件名称
4. appendfilename "appendonly.aof"
5. # 指定存储AOF文件的文件夹名称
6. appenddirname "appendonlydir"
7. # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置
8. 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 写入一次数据至磁盘
  

配置项如下：

1. appendfsync everysec

复制代码

至于这三种策略是如何实现的，其实只是在控制 fsync() 函数的调用时机
当应用程序向文件写入数据时，内核通常先将数据复制到内核缓冲区中，然后排入队列，然后由内核决定何时写入硬盘
如果想要应用程序向文件写入数据后，能立马将数据同步到硬盘，就可以调用 fsync() 函数，这样内核就会将内核缓冲区的数据直接写入到硬盘，等到硬盘写操作完成后，该函数才会返回

• Always 策略就是每次写入 AOF 文件数据后，就执行 fsync() 函数
  
• Everysec 策略就会创建一个异步任务来执行 fsync() 函数
  
• No 策略就是永不执行 fsync() 函数
  

3. 重写 AOF 文件

AOF 持久化机制会记录每个写命令，因此 AOF 文件会越来越大，会影响数据恢复的效率。AOF 文件重写会将内存中的数据库内容用命令的方式重写一个新的 aof 文件，替换原有文件，减小 aof 文件体积
3.1 触发重写的方式

第一种方式：客户端执行 BGREWRITEAOF 命令触发重写，不会阻塞 redis 服务
第二种方式：在服务器配置自动触发

1. auto-aof-rewrite-percentage 100
2. auto-aof-rewrite-min-size 64mb

复制代码

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

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

1. # 前面讲过,AOF是调用fsync()函数将写操作记录写回磁盘,这会占用一定的磁盘I/O
2. # 如果设为yes,相当于appendfsync no,不会执行写磁盘操作,只是写入缓冲区,缓解磁盘压力
3. no-appendfsync-on-rewrite no
4. # 在Redis启动过程中,当AOF数据重新加载回内存时,可能会发现AOF文件在最后被截断
5. # 如果设置为yes,则加载一个截断的AOF文件,并通过日志告诉用户该事件
6. # 如果设置为no,服务器将因错误而中止并拒绝启动,用户需要使用“redis-check-aof”实用程序修复AOF文件
7. aof-load-truncated yes
8. # 开启混合持久化,下面会提到
9. aof-use-rdb-preamble yes
10. # 支持在aof中记录时间戳,可以在特定时间恢复数据,但会改变aof格式,可能跟已经存在的aof文件不兼容
11. aof-timestamp-enabled no

复制代码

RDB 和 AOF 混合方式

Redis4.0 提出了一个混合使用 AOF 日志和内存快照的方法，混合持久化同样也是通过 bgrewriteaof 重写命令完成的，不同的是，当开启混合持久化后，fork 出的子进程先将共享的内存副本全量的以 RDB 方式写入 aof 文件，然后在将重写缓冲区的增量命令以 AOF 方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件

配置如下：

1. 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
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！