Redis 持久化机制

概述

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

  • 快照(Snapshot)
  • AOF(Append Only File)只追加日志文件

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

快照(Snapshot)

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

1. 快照生成方式

1.1 客户端方式

Redis 提供了两个命令来生成 RDB 文件,分别是 savebgsave,他们的区别就在于: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 创建一个子进程,子进程负责将快照写入磁盘,父进程则继续处理命令

Redis 持久化机制插图

父进程可以继续执行命令,也就是数据能被修改,关键在于使用了「写时复制技术」,通过 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 重写流程

Redis 持久化机制插图1

  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 文件

Redis 持久化机制插图2

配置如下:

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

文章来源于互联网:Redis 持久化机制

THE END
分享
二维码