Redis持久化：

什么是Redis持久化：

Redis 持久化是指将 Redis 内存中的数据保存到硬盘等持久化存储介质中，以便在 Redis 服务器重启或出现故障时能够恢复数据，保证数据的可靠性和持续性。Redis 提供了两种主要的持久化方式：RDB（Redis Database）持久化和 AOF（Append Only File）持久化。

我们可以采取的方案有四个：

RDB持久化
AOF持久化
RDB+AOF
不做任何持久化的操作

RDB持久化概念：

RDB 持久化是将 Redis 在某一时刻的内存数据快照保存到磁盘上的一种持久化方式，它生成的文件是一个紧凑的二进制文件，也被称为 RDB 文件。

RDB基础配置：

redis可以通过命令：config get <String 字段名> 获取配置文件中的值。

小编当前的Redis版本是：redis-6.2.7 版本

触发机制：

自动触发

RDB 持久化可以根据配置文件中设置的自动保存条件触发。自动保存条件通常是基于时间和数据变化量来设置的，例如 “save 900 1” 表示在 900 秒内如果至少有 1 个键发生了变化，就会触发 RDB 快照。

版本区别：

在redis的6.2~7的版本我们的触发机制出现了变化，在之前的版本中，我们的自动触发时间有了变化。

在6.0.16及之前的版本中，默认时间是：

如果没有手动配置 RDB 持久化的触发时间，Redis 默认的触发条件：

save 900 1：表示 900 秒（15 分钟）内至少有 1 个键被更改时，触发 RDB 快照。
save 300 10：即 300 秒（5 分钟）内至少有 10 个键被更改时，执行 RDB 持久化操作。
save 60 10000：意味着 60 秒内至少有 10000 个键被更改，会触发 RDB 快照。

在新版中，他的时间变为了

数据的恢复：

FLUSHALL 和 FLUSHDB 是 Redis 中用于清空数据的命令，如果我们执行这两个数据时，也会产生dump.rdb文件，这个rdb文件就是空的了。是没有意义的

我们使用shutdown命令关闭redis时，也会产生rdb文件，将当前快照保存。

SHUTDOWN 命令的主要作用是关闭 Redis 服务器。在关闭之前，它会先执行持久化操作，确保内存中的数据按照配置的持久化策略保存到磁盘，之后再正常关闭服务。

假设我们将一个时间的快照保存下来，将这个文件复制一份放置到别的文件夹下，之后用的时候按着这个文件回复当前快照的数据。

redis在启动时，按着我们这个文件进行恢复。

在物理恢复时，我们要将redis服务器和备份文件分开各自存储，放置生产机物理损坏之后备份文件挂到。（备份隔离）

手动触发：

RDB 持久化可以通过手动执行命令（如 SAVE 或 BGSAVE）来触发。

SAVE：这是一个同步命令。当你在 Redis 客户端输入 SAVE 命令后，Redis 服务器会立即停止处理客户端的其他请求，全身心投入到将内存中的数据写入 RDB 文件的工作中。只有当数据全部写入完成，生成 RDB 文件后，服务器才会继续响应其他客户端的请求。

BGSAVE（默认）：这是一个异步命令。当执行 BGSAVE 命令时，Redis 服务器会 fork 出一个子进程。这个子进程负责将内存中的数据写入 RDB 文件，而父进程（也就是主 Redis 进程）会继续处理客户端的请求，不会被阻塞。

生产上是bgsave,不能是save

通过lastsave 获取最后一次成功执行的快照时间

Linux上转化时间戳的命令：

[root@localhost bin]# date -d @15454545
1970年 06月 29日星期一 04:55:45 CST

优缺点

优点：
- 数据恢复快：RDB 文件是一个紧凑的二进制文件，在恢复数据时，Redis 可以快速地将 RDB 文件中的数据加载到内存中，相比其他一些持久化方式，恢复速度通常较快。
- 适合大规模数据备份：RDB 文件可以方便地进行备份和传输，适合用于数据的远程备份和归档，例如可以定期将 RDB 文件复制到其他存储设备或远程服务器上。
- 对性能影响小：在生成 RDB 文件时，使用子进程进行数据写入，对 Redis 主进程的性能影响相对较小，特别是在数据量较大时，这种方式的性能优势更为明显。
缺点：
- 数据一致性问题：RDB 持久化是基于一定的时间间隔进行数据快照的，所以在两次快照之间如果发生服务器故障，可能会丢失一部分数据。例如，如果设置了每 5 分钟进行一次 RDB 快照，那么在这 5 分钟内的数据变化在服务器故障时就可能会丢失。
- 内存占用问题：在生成 RDB 文件时，需要 fork 子进程，而子进程会复制父进程的内存空间，这在内存占用上会有一定的开销，特别是在内存数据量较大的情况下，可能会导致短暂的内存压力。

RDB文件的修复

假设我们的rdb文件再写入时出现了破损。该如何修复呢：

命令行：./redis-check-rdb dump.rdb

那些情况会出现dump.rdb文件：

符合save后的触发情况
手动的save,bgsave命令
执行flushadd,flushdb命令，但是文件是空的
执行shutdown，并且没有开启AOF持久化
主从复制时，主节点自动触发

如何禁用快照：

执行命令，动态禁用：config set save ""

修改配置文件，添加 save "" 就会禁用

优化配置项：

默认yes

如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，

也能确保redis继续接受新的写请求

默认yes

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

默认yes

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

AOF持久化：

AOF 持久化是通过将 Redis 服务器接收到的每一条写命令追加到一个以追加模式打开的文件中，来记录数据库的变化。当 Redis 服务器重启时，它会重新执行 AOF 文件中的命令，以重建数据库状态，从而实现数据的恢复。

默认是不开启的，需要配置我们的配置文件。讲appendonly 设置为yes

aop写入流程：

1	Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2	在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3	AOF缓冲会根据AOF缓冲区 *同步文件的三种写回策略*将命令写入磁盘上的AOF文件。
4	随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称 *AOF重写)*，从而起到AOF文件压缩的目的。
5	当Redis Server 服务器重启的时候会从AOF文件载入数据。

三种写回策略：

Always:同步回写，每个写命令执行之后立刻同步将日志写回到磁盘（IO频繁）

everysec:(默认)：每秒写回，每个写命令执行完，只是先把日志写道AOF文件的内存缓冲区中，每秒写入到磁盘中，每秒写一次

no:操作系统控制的写回，每个写命令执行完，只是先把日志写道AOF文件的内存缓冲区中，有操作系统决定何时将数据写入到磁盘。

AOF配置的设置：

在redis配置文件中redis7中对于AOF上有很大的优化。下文中介绍6和7的配置文件讲解。

打开AOF持久化机制：

设置写回策略：

在打开之后，我们只要就会发现在我们的路径之下出现了一个文件appendonly.aof

设置AOF文件保存路径：

在这里我们的redis有了变化：

在我们的redis6中，他的文件的位置和我们的的dump.rdb文件位置是一致的，都是通过config中的dir设置。

在redis7中，我们dir下，RDB文件的位置不变，但是在这个位置会出现一个子文件夹，子文件夹的名字就是我们appenddirname键值对的值

设置AOF文件保存名称：

redis6中，名字就是

在redis7中，不再是一个aof文件，变成了三个文件

官网的信息是：

aof文件的修复：

假设我们的aof文件出现问题时：例如我们当前的写入数据大，一秒写入时没有写完，但是在下一秒redis直接宕机，这是我们的redis在aof文件出现问题时，没有办法运行redis.需要进行文件修复。

检查环境变量的命令是：echo $PATH

修复的命令是：redis-check-aof --fix <String fileName>

AOF的优缺点：

优点

1. 数据安全性高

AOF 持久化以日志形式记录写操作，默认配置下，即使服务器发生故障，最多只会丢失 1 秒钟内执行的写命令。这是因为 Redis 可以配置为每秒将 AOF 缓冲区中的内容同步到磁盘，若使用always同步策略，每个写命令都会立即同步到磁盘，最大程度减少数据丢失风险。
相比 RDB（Redis Database）持久化在特定时间点生成快照，AOF 能更及时地记录数据变更，在遇到服务器崩溃等异常情况时，能更好地保证数据完整性。

2. 日志文件可读性强

AOF 文件是一个纯文本文件，记录的是 Redis 执行的写命令，例如SET key value、INCR counter等。这使得管理员可以方便地查看和分析文件内容，排查问题。
当需要恢复数据时，可以直接查看 AOF 文件，了解数据的变更历史，必要时还能手动修改文件内容。

3. 易于实现数据恢复

在 Redis 重启时，会按照 AOF 文件中记录的命令顺序依次执行，将数据恢复到故障前的状态。
与 RDB 相比，AOF 在数据恢复过程中不需要像 RDB 那样等待生成快照文件，恢复速度通常更快，尤其对于数据量较大的场景，优势更明显。

4. 支持追加式写入

AOF 文件采用追加方式写入，写操作是顺序的，避免了随机磁盘 I/O，提高了写入性能。
随着 Redis 服务器的运行，新的写命令会不断追加到 AOF 文件末尾，不会影响之前已记录的内容。

缺点

1. AOF 文件体积较大

由于 AOF 文件记录了所有写命令，随着时间推移和服务器的持续运行，文件会不断增大。
对于频繁执行写操作的 Redis 实例，AOF 文件可能会变得非常庞大，占用大量磁盘空间，同时也会增加文件管理和传输的难度。

2. 恢复速度可能较慢

虽然一般情况下 AOF 恢复速度比 RDB 快，但在 AOF 文件非常大时，Redis 在重启时需要执行大量的命令来恢复数据，这会导致恢复时间变长。
特别是在使用always同步策略时，由于每次写命令都要同步到磁盘，会产生更多的 I/O 操作，进一步影响恢复速度。

3. 性能开销较大

与 RDB 持久化相比，AOF 持久化需要更多的磁盘 I/O 操作。尤其是在使用always同步策略时，每个写命令都会立即同步到磁盘，会显著降低 Redis 的写性能。
即使使用everysec（每秒同步一次）策略，在高并发写操作场景下，频繁的磁盘 I/O 也会成为性能瓶颈。

4. AOF 重写带来额外开销

为了解决 AOF 文件体积过大的问题，Redis 会定期或手动执行 AOF 重写操作，将 AOF 文件中的冗余命令合并。
AOF 重写过程需要消耗额外的 CPU 和内存资源，可能会对 Redis 服务器的性能产生一定影响。

AOF重写机制：

自动触发:

在我们的aof文件较大时(达到阈值时),就会触发aof文件的重写,重写的文件会对指令进行压缩,新的文件中只是保留可以恢复数据的最小指令集.

阈值大小是:

redis7配置文件:

redis6配置文件:

配置文件没有变化,他的意思是文件大小变为以前的2倍,并且大于64mb机会触发重写.

但是对于7和6的文件的写的格式是不一样的.

redis7:

在我们的incr文件达到阈值时,开始进行重写,这时我们的重写结束后我们的文件名也会发生变化

手动触发:

执行客户端命令:

BGREWRITEAOF

整体上重写的过程

这里需要考率的是如果在重写时我们的数据还在继续的写入,这是整体的流程是什么:

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。(其实这里也是他的缺点,子进程加大内存开销)

2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

RDB+AOF混合持久化:

如果使用这种方式持久化时,他们的优先级是:

在同时开启时,优先加载的时aof文件.

官网推荐使用两种方式共存的形式进行数据持久化操作.

如何开启混合模式:

开启的配置:

这个配置的前置条件是必须开启aof.

注意点:

在 Redis 中，aof-use-rdb-preamble 和 appendonly 是两个不同的配置项，它们分别控制着 AOF（Append Only File）持久化相关的不同特性。下面来分析设置 aof-use-rdb-preamble 为 yes 时，若 appendonly 设置为 no 是否能达成预期目的。

配置项含义

aof-use-rdb-preamble：这个配置项用于控制 AOF 重写时的文件格式。当设置为 yes 时，AOF 重写后的文件开头会包含一个 RDB 格式的快照，之后才是 AOF 格式的增量命令。这种方式能让 AOF 文件在恢复数据时，先利用 RDB 快照快速加载大部分数据，再通过执行 AOF 中的增量命令来恢复最新的数据，提升恢复速度。
appendonly：此配置项用于开启或关闭 AOF 持久化功能。当设置为 yes 时，Redis 会开启 AOF 持久化，将写命令追加到 AOF 文件中；当设置为 no 时，Redis 会关闭 AOF 持久化，仅使用 RDB 持久化（如果开启了 RDB 持久化的话）。

分析设置结果

当 aof-use-rdb-preamble 设置为 yes，而 appendonly 设置为 no 时，无法达成使用 aof-use-rdb-preamble 特性的目的。原因如下：

aof-use-rdb-preamble 特性是基于 AOF 持久化的，它主要影响 AOF 重写后的文件格式。若 appendonly 设置为 no，AOF 持久化功能被关闭，Redis 不会生成 AOF 文件，也就不存在 AOF 重写操作，那么 aof-use-rdb-preamble 的配置就没有实际意义。

示例配置说明

假设你有如下配置需求：

plaintext
aof-use-rdb-preamble yes
appendonly no
在这种配置下，由于 appendonly 为 no，Redis 不会开启 AOF 持久化，即使 aof-use-rdb-preamble 设置为 yes，也不会有包含 RDB 预 amble 的 AOF 文件生成。

若你想使用 aof-use-rdb-preamble 特性来优化 AOF 文件恢复速度，需要将 appendonly 设置为 yes，示例配置如下：

plaintext
aof-use-rdb-preamble yes
appendonly yes
这样配置后，Redis 会开启 AOF 持久化，并且在 AOF 重写时会采用包含 RDB 预 amble 的文件格式。

综上所述，设置 aof-use-rdb-preamble 为 yes 时，若 appendonly 设置为 no，无法达成使用该特性的目的，需要将 appendonly 设置为 yes 才能生效。