redis 持久化
Redis是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。# 持久化的方式
快照方式
快照是某时某刻对数据的完整备份。在以下数据持久化时被使用:
- MySQL Dump
- Redis RDB
日志
数据库做任何操作的更新就将它记录在日志中,当某时刻需要将数据恢复的时候,只需要将日志中的操作重新执行一遍,便得到某时某点的完整数据。在以下数据持久化时被使用:
- MySQL Binlog
- Hbase HLog
- Redis AOF
redis持久化方式
RDB
经过RDB之后,redis会将内存中的数据创建一份快照到硬盘中,称为RDB文件(二进制,直接查看是乱码)。当redis重新启动时,会加载硬盘中的RDB文件,加载到内存中完成数据恢复。
RDB 的触发方式 - 主要三种方式
- save(同步–命令)
- bgsave(异步–命令)
- 自动(配置文件中设置)
save(同步)
执行流程如下:
- 在 save 的同时,其他命令会阻塞等待
- 如果存在老的 RDB 文件,会先创建一个临时文件,然后对老文件进行替换
- 时间复杂度,O(n)
bgsave(异步)
执行流程如下:
- 调用 bgsave 后,会调用 linux 的 fork() 函数,创建一个子进程
- 如果存在老的 RDB 文件,会先创建一个临时文件,然后对老文件进行替换
- 时间复杂度,O(n)
- 子进程名称:redis-rdb-bgsave
自动方式
- 内部相当于bgsave
- Redis(6.2.6版本)默认的save配置如下表:
配置 | second | changes |
---|---|---|
save | 3600 | 1 |
save | 300 | 100 |
save | 60 | 10000 |
满足以上任一条件,将创建(bgsave)RDB 文件(二进制)。比如 60秒内,有10000 条数据发生改变,将自动生成 RDB 文件。此方式的优点是生成的二进制文件是紧凑型的,可按需备份,而且通过RDB恢复数据的速度远远快于AOF。缺点是不好控制 RDB 文件的生成,如果写入量很大的话 RDB 生成太过频繁,频繁写入硬盘,对硬盘负担很大;无法实时持久化(bgsave每次都要fork建立子进程,属于重量级操作),且生成的文件是二进制文件,新旧版本可能存在不兼容的情况。
RDB 相关配置
配置项 | 默认值 | 含义 |
---|---|---|
dbfilename | dump.rdb | RDB快照文件名 |
dir | ./ | RDB快照文件生成所在目录 |
stop-writes-on-bgsave-error | yes | bgsave时发生错误是否停止写入 |
rdbcompression | yes | RDB文件是否采用压缩 |
rdbchecksum | yes | 是否对RDB进行校验 |
RDB 最佳配置
- 不配置自动RDB操作
- dbfilename dump-${port}.rdb
- dir /redisDataPath
- stop-writes-on-bgsave-error yes
- rdbcompression yes
- rdbchecksum yes
触发机制
以下几种情况会触发生成快照:
- 客户端执行命令save和bgsave时会生成快照
- 根据配置文件save m n规则进行自动快照
- 主从复制时从节点执行全量复制,master 节点会执行 bgsave并将RDB文件发给从节点
- debug reload命令重新加载redis
- 默认执行shutdown时,如果没有开启AOF,则自动执行bgsave
- 客户端执行shutdown关闭redis时,触发快照
AOF
通过日志方式将redis中的写命令进行日志记录,保存在硬盘文件中。日志记录的实质是将写命令写在硬盘的缓冲区中,再根据相关策略把数据刷新到磁盘中。当redis服务器启动时候,执行硬盘中的日志文件以恢复redis中的数据。如果日志文件很大(数据量大),恢复速度可能比较慢。
AOF 运行原理 - 创建
AOF 运行原理 - 恢复
AOF 的三种刷新策略
策略 | 含义 |
---|---|
always | 执行每条写命令都会将写命令写到磁盘中 |
everysec | 每秒将数据从缓冲区刷到磁盘中,可能会丢失一秒的数据(redis 默认使用该策略) |
no | 写命令何时刷新的磁盘中,由操作系统来决定 |
AOF 重写
注意这里的重写并不是说将 redis 命令重新抽象成新的 redis 命令,再写入 AOF 文件,而是执行 redis 命令后将内存中的数据进行回溯,重写成 AOF 文件。
- 重写的作用:减少磁盘占用(过期的数据不再写入文件,无效的命令不再写入文件)、加速AOF恢复速度(命令合并)
例如一千次incr key 可以重写为 set key 1000 - AOF 重写实现方式 - bgrewriteaof
客户端发送出一条bgrewriteaof命令后,redis会fork一个子进程完成AOF重写操作逻辑。
AOP 重写实现方式 - AOF 重写配置
- AOF配置项
配置 | 默认值 | 含义 |
---|---|---|
auto-aof-rewrite-min-size | 64MB | AOF文件重写需要的尺寸,AOF多大时开启重写 |
auto-aof-rewrite-percentage | 100 | AOF文件增长率(当前AOF文件大小超过上一次重写的AOF文件大小的百分之多少才会重写) |
- AOF统计项
统计名 | 含义 |
---|---|
aof_current_size | AOF当前尺寸(单位:字节) |
aof_base_size | AOF上次启动和重写的尺寸(单位:字节) |
- 自动触发时机
- 当前 AOF 文件大小超过最小重写尺寸
- 当前 AOF 文件大小超过上次重写完的 AOF 尺寸的百分之多少(auto-aof-rewrite-percentage)
aof_current_size > auto-aof-rewrite-min-size
(aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage
AOF 相关配置
配置项 | 最佳取值 | 含义 |
---|---|---|
appendonly | yes | 开启AOF |
appendfilename | aof-${port}.aof | AOF文件名 |
appendfsyn | c everysec | AOF策略 |
dir | /redisDataPath | AOF文件所在目录 |
no-appendfsync-no-rewrite | yes | 在执行重写时不进行AOF操作 |
auto-aof-rewrite-percentage | 100 | AOF重写配置(见上文) |
auto-aof-rewrite-min-size | 64MB | AOF重写配置(见上文) |
AOF 重写原理
AOF 重写流程示意图如下:
说明:
- bgrewriteaof触发重写,判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
- 主进程fork出子进程执行重写操作,保证主进程不会阻塞。
- 子进程遍历redis内存中数据到临时文件,客户端的写请求继续写入aof_buf 缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
- 子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
- 使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。
RDB-AOF混合持久化
在redis4.0版本中,相对与之前的版本其中一个比较大的变化是4.0添加了新的混合持久化方式。所谓的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据,缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式,可读性差。
开启混合持久化
在6.0版本的redis中混合持久化默认关闭的,通过aof-use-rdb-preamble配置参数控制,yes则表示开启,no表示禁用,默认是禁用的,可通过config set修改。
混合持久化过程
混合持久化同样也是通过bgrewriteaof完成的,不同的是当开启混合持久化时,fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。
数据恢复
当我们开启了混合持久化时,启动redis依然优先加载aof文件,aof文件加载可能有两种情况如下:
- aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
- aof文件开头不是rdb的格式,直接以aof格式加载整个文件。
127.0.0.1:6379> DBSIZE
(integer) 7
127.0.0.1:6379> CONFIG sET aof-use-rdb-preamble yes
OK
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting starte
退出查看,或者另一个终端查看aof文件
也可以通过redis自带的检查命令去检查一下持久化文件是否正确。
[root@k8s-m2 redis]# ./src/redis-check-rdb dump.rdb
[offset 0] Checking RDB file dump.rdb
[offset 26] AUX FIELD redis-ver = '6.2.6'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1704348988'
[offset 67] AUX FIELD used-mem = '831144'
[offset 83] AUX FIELD aof-preamble = '0'
[offset 85] Selecting DB ID 0
[offset 107] Checksum OK
[offset 107] \o/ RDB looks OK! \o/
[info] 2 keys read
[info] 0 expires
[info] 0 already expired
[root@k8s-m2 redis]# ./src/redis-check-aof /appendonly.aof
The AOF appears to start with an RDB preamble.
Checking the RDB preamble to start:
[offset 0] Checking RDB file /appendonly.aof
[offset 26] AUX FIELD redis-ver = '6.2.6'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1709537259'
[offset 67] AUX FIELD used-mem = '872648'
[offset 83] AUX FIELD aof-preamble = '1'
[offset 85] Selecting DB ID 0
[offset 132] Checksum OK
[offset 132] \o/ RDB looks OK! \o/
[info] 7 keys read
[info] 0 expires
[info] 0 already expired
RDB preamble is OK, proceeding with AOF tail...
AOF analyzed: size=132, ok_up_to=132, ok_up_to_line=1, diff=0
AOF is valid
持久化方式对比
RDB
- 优点:RDB 文件紧凑,体积小,因此在传输速度上比较快,因此适合全量恢复。
RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 - 缺点:RDB是一个快照过程,无法完整的保存所以数据,尤其在数据量比较大时候,一旦出现故障丢失的数据将更多。
当redis中数据集比较大时候,RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件,fork的子进程会耗CPU,并且数据越大,RDB快照生成会越耗时。
RDB文件是特定的格式,阅读性差,由于格式固定,可能存在不兼容情况。
AOF
- 优点:数据更完整,秒级数据丢失(取决于设置fsync策略)。
兼容性较高,由于是基于redis通讯协议而形成的命令追加方式,无论何种版本的redis都兼容,再者aof文件是明文的,可阅读性较好。 - 缺点:数据文件体积较大,即使有重写机制,但是在相同的数据集情况下,AOF文件通常比RDB文件大。
相对RDB方式,AOF速度慢于RDB,并且在数据量大时候,恢复速度AOF速度也是慢于RDB。
由于频繁地将命令同步到文件中,AOF持久化对性能的影响相对RDB较大,但是对于我们来说是可以接受的。
混合持久化
- 优点:
混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式,加载速度快,同时结合AOF,增量的数据以AOF方式保存了,数据更少的丢失。 - 缺点:兼容性差,一旦开启了混合持久化,在4.0之前版本都不识别该aof文件(兼容性问题),同时由于前部分是RDB格式,阅读性较差。
更多关于redis的知识分享,请前往博客主页。编写过程中,难免出现差错,敬请指出