目录
# 概念
1. RDB持久化
1.1 备份是如何执行的(RDB过程)
1.2 配置文件信息
1.3 RDB持久化操作
1.4 RDB优势
1.5 RDB劣势
1.6 RDB做备份
2. AOF持久化
2.1 AOF开启及使用
2.2 异常恢复
2.3 配置文件操作
2.4 AOF持久化流程
2.5 优点
2.6 劣势
# 概念
-
redis持久化概念
redis是我们的内存数据,存在内存中的,但是redis也可以写道硬盘中去,这个过程就叫持久化;
-
RDB与AOF的优先级
AOF和 RDB 同时开启,系统默认取 AOF的数据(数据不会存在丢失);
1. RDB持久化
-
概念
就是在指定的时间间隔中将内存中的数据集快照写入到磁盘中(硬盘是磁盘的一种),比如每个10秒写入一次,再过10秒写入一次等;
1.1 备份是如何执行的(RDB过程)
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失;
-
Fork:
Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程;
在 Linux 程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会 exec 系统调用,出于效率考虑,Linux 中引入了“写时复制技术”;
一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程;
dump.rdb文件:
1.2 配置文件信息
配置文件存在:vim /etc/redis.conf
一、stop-writes-on-bgsave-error yes(当redis无法写入磁盘,直接关闭redis写操作,推荐yes)
二、rdbcompression yes(对于存储到磁盘中的快照,设置是否进行压缩存储)
对于存储到磁盘中的快照,设置是否进行压缩存储。如果是,redis会采用LZF算法进行压缩;
如果不想消耗CPU进行压缩,可以设置为关闭此功能,推荐yes;
三、rdbchecksum检查完整性(存储快照后让redis使用CRC64算法进行数据校验)
推荐yes;
四、Save秒钟(写操作次数)
- 在 Redis 的配置文件中,
save
命令用于配置数据库的 RDB(Redis Database)持久化策略。它定义了在特定时间间隔内,如果发生了一定数量的键改变,Redis 将触发持久化操作,将数据保存到磁盘中。
这三条配置定义了 Redis 在以下条件下触发持久化的规则:
save 900 1
:- 时间间隔: 900秒(15分钟)。
- 键改变数量: 至少1个键。
- 解释: 如果在900秒内,至少有1个键发生了变化(被修改、删除或新增),Redis 将触发一次持久化操作,将数据保存到磁盘。
save 300 10
:- 时间间隔: 300秒(5分钟)。
- 键改变数量: 至少10个键。
- 解释: 如果在300秒内,至少有10个键发生了变化,Redis 将触发一次持久化操作,将数据保存到磁盘。
save 60 10000
:- 时间间隔: 60秒(1分钟)。
- 键改变数量: 至少10000个键。
- 解释: 如果在60秒内,至少有10000个键发生了变化,Redis 将触发一次持久化操作,将数据保存到磁盘。
-
运行原理
Redis 会在后台持续监视键的变化。如果在指定的时间间隔内键的变化次数达到设置的数量,Redis 就会创建一个 RDB 快照。这个快照包含当前数据库状态的一个副本并将其写入磁盘,以便于恢复数据。配置多个
save
条目可以根据不同的条件灵活地触发持久化操作。 -
配置的意义和影响
- 灵活的持久化策略: 不同时间间隔和键改变数量的配置使得 Redis 能够灵活处理持久化操作。在频繁变化的情况下(如
save 60 10000
),它能快速保存数据;而在变化较少的情况下(如save 900 1
),则不会频繁触发持久化,减少性能开销。 - 数据持久化: 这些配置确保了 Redis 的数据能够定期持久化到磁盘中,以防止数据丢失。
- 性能权衡: 更频繁的持久化会导致更多的磁盘 I/O,从而影响性能;而较少的持久化则可能在崩溃时导致更多的数据丢失。
- 灵活的持久化策略: 不同时间间隔和键改变数量的配置使得 Redis 能够灵活处理持久化操作。在频繁变化的情况下(如
五、save VS bgsave
-
save:
工作机制:
- 同步操作:
save
是一个同步操作,阻塞当前 Redis 实例,直到保存过程完成。 - 数据持久化: 它会生成一个 RDB (Redis Database) 快照文件,将当前的内存数据保存到磁盘。
优缺点:
- 优点: 操作简单,适合在 Redis 启动期间使用,确保启动时的数据被持久化。
- 缺点: 由于是同步操作,期间 Redis 将不能处理其他请求,可能导致性能问题,尤其在数据量大时。
典型使用场景:
- 紧急保存: 在进行数据恢复操作之前确保数据不丢失。
- 开发和调试: 当需要手动触发保存数据以查看具体状态时。
示例:
SAVE
- 同步操作:
-
bgsave:
工作机制:
- 异步操作:
bgsave
是一个异步操作,Redis 主进程会 fork 一个子进程来执行数据持久化。 - 数据持久化: 子进程会生成一个 RDB 快照文件,将当前的内存数据保存到磁盘,而主进程继续处理客户端的请求。
优缺点:
- 优点: 不阻塞 Redis 主进程,允许 Redis 继续处理其他请求,适合在运行时定期保存数据。
- 缺点: fork 操作在数据量大时可能会占用较多的系统资源,并且对系统内存开销较大。
典型使用场景:
- 定期备份: 在运行时定期进行数据备份,减少持久化对性能的影响。
- 大规模应用: 适合需要频繁持久化数据且不希望阻塞请求处理的大规模应用。
示例:
BGSAVE
- 异步操作:
-
主要区别总结
特性 | save | bgsave |
---|---|---|
操作模式 | 同步 | 异步 |
阻塞行为 | 阻塞 | 非阻塞 |
系统资源 | 较少 | 较多 |
执行时机 | 手动 | 手动或自动配置 |
性能影响 | 高 | 低 |
1.3 RDB持久化操作
设置key:
写入后查询(证明做了持久化操作):
1.4 RDB优势
适合大规模的数据恢复;
对数据完整性和一致性要求不高更适合使用;
节省磁盘空间;
恢复速度快;
1.5 RDB劣势
Fork 的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑;
虽然 Redis.在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能;
在备份周期在一定间隔时间做一次备份,所以如果 Redis 意外 down 掉的话就会丢失最后一次快照后的所有修改;
1.6 RDB做备份
我们在移除前先做一个插入操作,以上操作后重新启动redis,在删除dump文件后,进入复制的文件中查看,这时候就有之前设置的3个key了(save 20 3)这个是备份恢复过程;
2. AOF持久化
-
概念
(Append Only File:在redis中的另一种持久化的方式)
以日志的形式来记录每个写操作(增量保存),将 Redis 执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行-次以完成数据的恢复工作;
2.1 AOF开启及使用
开启后就会有默认文件:appendonly yes
使用(在开启完后在redis中set入值,这时候文件的大小发生了变化 )
2.2 异常恢复
修改默认的 appendonly no
,改为 yes;
如遇到 AOF文件损坏,通过/usr/local/bin/redis-check-aof--fix appendonly.aof
进行恢复;
作用:备份被写坏的 AOF 文件;
恢复:重启 redis,然后重新加载;
2.3 配置文件操作
1. AOF同步步率设置
appendfsync always
:始终同步,每次Redis的写入都会立刻记入日志;虽然性能较差,但数据完整性比较好;
appendfsync everysec
:每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失;
appendfsync no
:redis不主动进行同步,把同步时机交给操作系统;
2. rewrite压缩
-
rewrite是什么:
AOF 采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF 文件的大小超过所设定的阈值时,Redis 就会启动 AOF 文件的内容压缩 , 只保留可以恢复数据的最小指令集,可以使用命令 bgrewriteaof;
-
重写原理,如何实现重写:
AOF 文件持续增长而过大时,会 fork 出一条新进程来将文件重写(也是先写临时文件最后rename),redis4.0 版本后的重写,是指上就是把 rdb 的快照,以二级制的形式附在新的 aof头部,作为已有的历史数据,替换掉原来的流水账操作;
3. no-appendfsync-on-rewrite :AOF 是否继续同步数据到磁盘
在 Redis 中,no-appendfsync-on-rewrite
配置选项,与 AOF(Append Only File)持久化和 RDB(Redis Database)持久化的相互作用相关。这个选项控制了在执行 RDB 快照的同时,AOF 是否继续同步数据到磁盘;
no-appendfsync-on-rewrite
的值为 no
时(默认情况):
- AOF 重写期间继续 ****
fsync
: 在进行 RDB 持久化(快照)或 AOF 重写时,Redis 将继续按照appendfsync
配置进行fsync
操作,将 AOF 缓冲区中的数据同步到磁盘。 - 保持 AOF 持久化的完整性: 即使在进行快照或 AOF 重写期间,也不会延迟或暂停 AOF 文件的同步操作,确保 AOF 文件的实时性和数据完整性。
no-appendfsync-on-rewrite
的值为 yes
时:
- AOF 重写期间暂停 ****
fsync
: 在进行 RDB 持久化或 AOF 重写时,Redis 会暂停fsync
操作。这意味着在持久化操作期间,AOF 文件的数据不会实时同步到磁盘。 - 降低磁盘 I/O 负载: 通过暂停
fsync
,可以减轻磁盘 I/O 负载,减少系统压力和潜在的性能影响,适合 I/O 密集型应用或磁盘性能有限的环境。
2.4 AOF持久化流程
(1)客户端的请求写命令会被append追加到 AOF 缓冲区内;
(2)AOF缓冲区根据 AOF持久化策略[always,everysec,no]
将操作sync 同步到磁盘的AOF文件中;
(3)AOF文件大小超过重写策略或手动重写时,会对 AOF 文件rewrite 重写,压缩AOF 文件容量;
2.5 优点
备份机制更稳健,丢失数据概率更低;
可读的日志文本,通过操作 AOF文件,可以处理误操作;
2.6 劣势
比起 RDB 占用更多的磁盘空间;
恢复备份速度要慢;
每次读写都同步的话,有一定的性能压力;
存在个别 Bug,造成不能恢复;