“Redis中的持久化：深入理解RDB与AOF机制“

[# 概念](# 概念)

[1. RDB持久化](#1. RDB持久化)

[1.1 备份是如何执行的（RDB过程）](#1.1 备份是如何执行的（RDB过程）)

[1.2 配置文件信息](#1.2 配置文件信息)

[1.3 RDB持久化操作](#1.3 RDB持久化操作)

[1.4 RDB优势](#1.4 RDB优势)

[1.5 RDB劣势](#1.5 RDB劣势)

[1.6 RDB做备份](#1.6 RDB做备份)

[2. AOF持久化](#2. AOF持久化)

[2.1 AOF开启及使用](#2.1 AOF开启及使用)

[2.2 异常恢复](#2.2 异常恢复)

[2.3 配置文件操作](#2.3 配置文件操作)

[2.4 AOF持久化流程](#2.4 AOF持久化流程)

[2.5 优点](#2.5 优点)

[2.6 劣势](#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，从而影响性能；而较少的持久化则可能在崩溃时导致更多的数据丢失。

五、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 配置文件操作

AOF同步步率设置

appendfsync always：始终同步，每次Redis的写入都会立刻记入日志；虽然性能较差，但数据完整性比较好；

appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失；

appendfsync no：redis不主动进行同步，把同步时机交给操作系统；

rewrite压缩

rewrite是什么：

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof；
重写原理，如何实现重写：

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写（也是先写临时文件最后rename），redis4.0 版本后的重写，是指上就是把 rdb 的快照，以二级制的形式附在新的 aof头部，作为已有的历史数据，替换掉原来的流水账操作；

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，造成不能恢复；