Redis7——基础篇（三）

前言：此篇文章系本人学习过程中记录下来的笔记，里面难免会有不少欠缺的地方，诚心期待大家多多给予指教。

基础篇：

接上期内容：上期完成了Redis的基本命令学习。下面开始学习Redis的持久化，话不多说，直接发车。

一、持久化定义

1、什么是持久化？

持久化，简单来说，就是将数据从易失性存储（如内存）保存到非易失性存储（如硬盘）的过程。在计算机系统中，内存虽然读写速度极快，但一旦断电，数据就会丢失。而硬盘等非易失性存储设备可以长期保存数据，即使在系统断电后，数据依然存在，除非硬盘损坏。

2、redis为什么要持久化？

Redis作为一款高性能的内存数据库，数据默认存储在内存中。这使得它在处理读写操作时能够达到极高的速度，但也带来了一个问题：一旦 Redis 服务器重启或者发生故障，内存中的数据就会全部丢失。为了避免这种情况，Redis 需要持久化机制，将内存中的数据保存到硬盘上，以便在需要时能够快速恢复数据，保证数据的完整性和可用性。

二、持久化方式

1、RDB（Redis Database）

1、定义

RDB是Redis默认的持久化方式。它会在指定的时间间隔内，对当前内存中的数据进行快照，生成一个二进制文件（dump.rdb）。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使服务器故障宕机，快照文件也不会丢失，数据的可靠性得到了保证。

2、实操

2.1、自动触发

1、修改配置

bash 复制代码

save <seconds> <changes> [<seconds> <changes> ...]

用vim 打开/myredis/redis.conf文件

本次案例修改为5秒2次

2、修改保存路径

同样用vim 打开/myredis/redis.conf文件，修改备份文件存储路径为**/myredis/dumpfiles，记得新建目录文件夹。** 后续在redis客户端通过config get dir 命令来查看保存路径。

3、修改保存文件名

同样用vim 打开/myredis/redis.conf文件，改为端口号加文件名，方便后续查看日志。

4、触发备份

5秒内连续2次修，会触发备份。

设置第三个key后，停留超过5秒，依旧触发备份。

5、恢复备份

先拷贝一份完整的rdb文件。原因是：执行FLUSHDB或FLUSHALL命令也会产生rdb文件。

执行FLUSHDB清空redis，并关机。

重启redis服务，验证数据是否成功恢复。

没有数据的原因是：FLUSHDB命令执行成功后，因为save 5 2的规则存在，会触发RDB备份，本来之前的数据都已经成功清除了，所以RDB备份了空数据。

删除原有的rdb文件，使用备份的rdb进行数据恢复。（数据恢复成功 ）

2.2、手动触发

Redis提供了两个命令来生成RDB文件分别是save 和bgsave。

1、save

在主程序中执行会阻塞当前redis服务器，直到持久化工作完成。执行save命令期间，Redis不能处理其他命令，线上禁止使用。

2、bgsave

Redis会在后台异步进行快照操作(不阻塞)，同时还可以响应客户端请求。该触发方式会fork一个子进程由子进程复制持久化过程。

LASTSAVE 命令可以查看上一次备份时间(返回的是时间戳)。

3、优劣势对比

优势

文件紧凑：RDB文件是一个紧凑的二进制文件，占用磁盘空间较小，方便进行数据备份和恢复。在恢复数据时，直接将 RDB文件读入内存即可，速度相对较快。
性能影响小：RDB在进行快照时，是通过fork子进程来完成的，主进程不需要进行任何磁盘 I/O 操作，因此对Redis的性能影响较小，非常适合大规模数据的恢复。

劣势

数据丢失风险：由于 RDB是按照一定的时间间隔进行快照的，如果在两次快照之间发生故障，那么这期间的数据将会丢失，数据丢失风险大。例如，设置每 5 分钟进行一次 RDB 快照，若在第 3 分钟时发生故障，那么从上次快照到第 3 分钟之间的数据都将丢失。
fork子进程开销：在进行快照时，fork子进程会消耗一定的内存和 CPU 资源，特别是在数据量较大时，可能会导致 Redis 服务器短暂的卡顿。

4、其他说明

1、修复RDB文件

2、禁用RDB备份数据

两种方式都没法禁用save和bgsave命令进行手动备份

方式一：动态禁用

bash 复制代码

redis-cli config save ""

这样设置后，save规则失效不会进行RDB备份，redis服务重启后恢复。

方式二：修改配置文件，将save ""注释打开，重启服务。

5、RDB其他配置项说明

stop-writes-on-bgsave-error：默认yes，如果配置成no，表示不在乎数据不一致，那么在快照写入失败时，能确保redis继续接收新的写请求。
rdbcompression：默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum：默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
rdb-del-sync-files：默认no，用于控制在没有持久化功能开启的情况下，是否同步删除在主从复制过程中使用的RDB文件。

6、小总结

2、AOF（Append Only File）

1、定义

AOF是另一种持久化方式，它以日志的形式记录Redis服务器所执行的每一个写操作 。当Redis服务器启动时，会读取AOF文件并重新执行其中的写操作，从而恢复数据到最新状态。

2、工作流程

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

3、AOF回写策略

3.1、Always

同步写回，每个写命令执行完立刻同步地将日志写回磁盘。

3.2、everysec

redis默认的回写策略，每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。

3.3、no

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

3.4、三种回写策略总结

|----------|-----------|--------------|------------------|
| 配置项 | 写回时机 | 优点 | 缺点 |
| Always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响较大 |
| Everysec | 每秒写回 | 性能适中 | 宕机时丢失1秒内的数据 |
| NO | 操作系统控制的写回 | 性能好 | 宕机时丢失数据较多 |

4、实操

4.1、正常恢复

1、修改配置文件

开启AOF

修改aof文件存储名字和路径(提前创建好目录)

重启redis服务

base.rdb:表示基础AOF，它一般由子进程通过重写产生，该文件最多只有一个。

incer.aof：表示增量AOF，它通常用于记录 Redis 执行的所有写操作命令。

manifest：一个文件清单，该文件用于记录 AOF 重写过程中各个文件的元信息，包括 base.rdb 文件和 incr.aof 文件的相关信息，如文件名、文件大小、生成时间等。Redis 可以通过读取这个清单文件，了解各个文件的状态和顺序，从而正确地进行数据恢复操作。

2、修复数据

先拷贝一份完整的aof文件。原因是：执行FLUSHDB或****FLUSHALL的命令也会写入aof中，会导致恢复的数据为空。

清空并关闭redis服务

修改aof文件名，重启redis服务，恢复数据成功。

4.2、异常恢复

模拟redis在进行AOF备份时，redis宕机，导致AOF文件写入命令不完整场景。

1、修改aof文件

使用vim 打开/myredis/appendonlyfiles/appendonly6379.aof.1.incr.aof文件，随便输入。

2、重启reids服务，（无法成功启动）。

原因：是因为redis无法通过aof文件进行数据恢复，导致redis启动失败。

3、修复aof文件

拷贝aof文件到 /usr/local/bin目录下，使用

redis-check-aof --fix  xxxx.aof

修复文件。

在将修复的文件放回原始目录，重启redis服务。

恢复成功。

5、AOF重写机制

5.1、是什么

随着 Redis服务的持续运行，不断有新的写命令被追加到 AOF 文件中，这会导致 AOF 文件变得越来越大。过大的 AOF 文件不仅会占用大量的磁盘空间，还会在 Redis 重启恢复数据时，因为需要执行大量的命令而导致恢复时间变长。

为解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件压缩，只保留可以恢复数据的最小指令集。

5.2、实操

1、自动触发

官方默认配置。触发条件：同时满足，且的关系才会触发。

根据上次重写后的aof大小判断当前aof大小是否增长了1倍
重写时是否满足的文件设置的大小

修改配置为1kb

关闭rdb和aof的混合模式

删除以前的rdb和aof文件，重启redis服务

不停设置key，修改key，使得aof文件达到重写的条件

查看.2.incr.aof文件

压缩后aof文件里面就只剩下了最小指令集，aof文件的大小也变小了。

2、手动触发

BGREWRITEAOF

3、总结

也就是说AOF文件重写并不是对原文件进行重新整理 ，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

5.3、重写原理

1、在重写开始前，redis会创建一个"重写子进程"，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

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

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

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

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

6、小总结

三、AOF+RDB混合模式

1、AOF vs RDB可否共存

答：可以共存。如共存优先加载AOF文件。

2、AOF和RDB共存时加载数据流程

3、推荐方式

推荐：AOF+RDB混合方式，结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

1、开启方式

设置aof-use-rdb-preamble的值为yes，yes表示开启，no表示禁用。

开启后，Redis 在进行 AOF 重写时，会将 AOF 文件的开头部分替换为 RDB 格式的数据快照，后续再以常规的 AOF 格式记录重写之后的写操作。

2、结论

RDB镜像做全量持久化，AOF做增量持久化。

先使用RDB进行快照存储，然后使用AOF持久化记录所有写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

四、纯缓存模式

同时禁用AOF + RDB

1、禁用RDB

配置文件开启save "" ，去掉注释。但是仍可以通过命令bgsave和save进行RDB备份

2、禁用AOF

配置文件设置appendonly no 。但是仍可以通过命令BGREWRITEAOF生成AOF文件。

五、总结

RDB 和 AOF 持久化方式各有优劣，混合模式则在一定程度上弥补了两者的不足。而纯缓存模式则适用于对数据可靠性要求不高，但对性能要求极高的场景。在实际应用中，我们需要根据具体的业务需求和场景，合理选择 Redis的持久化方式和应用模式，以充分发挥 Redis 的优势，提升系统的性能和稳定性。

ps：努力到底，让持续学习成为贯穿一生的坚守。学习笔记持续更新中。。。。