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才能生效。
纯缓存模式:
同时关闭RDB和AOF
关闭RDB:save "" 关闭AOF:appendonly no
即使是关闭之后依旧可以使用save,bgsave生成RDB文件,使用bgrewriteaof生成aof文件。
这是redis就只是一个缓存的作用。