【大家好，我是爱干饭的猿，本文重点介绍Redis7 持久化（重点：RDB与AOF重写机制）。

后续会继续分享Redis7和其他重要知识点总结，如果喜欢这篇文章，点个赞👍，关注一下吧】

上一篇文章：《【Redis7】Redis7 十大数据类型》

🥐1. RDB（Redis Data Base）

1.1 什么是RDB

1.2 Redis 6 和 7 的配置文件区别

1.3 RDB 的自动触发和手动触发

1.4 优势和劣势

1.5 其他

1. 如何检查修复dump.rdb文件

2. 哪些情况会触发RDB快照

3. 如何禁用快照

4. RDB优化配置项详解

🥐2. AOF（Append Only File）

2.1 什么是AOF

2.2 AOF 持久化工作流程

2.3 AOF 缓冲区三种写回策略

2.4 AOF 启动/恢复/修复

1. 启动

3. 正常恢复

4. 异常恢复

2.5 优劣势

2.6 AOF重写机制的自动触发和手动触发

2.7 AOF重写原理

2.8 AOF 优化配置项详解

🥐3. RDB - AOF混合持久化

🥐4. 纯缓存模式

🥐1. RDB（Redis Data Base）

1.1 什么是RDB

RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。

在指定的时间间隔，执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
将内存数据全部保存到磁盘dump.rdb文加中

1.2 Redis 6 和 7 的配置文件区别

Redis 7

1.3 RDB 的自动触发和手动触发

教程

自动触发

步骤：

Redis7版本，按照redis.conf里配置的save <seconds> <changes>
本次案例5秒2次
修改修改dump文件保存路径
修改dump文件名名称

触发备份条件：5秒内执行两次改变数据的操作。

如何恢复备份：

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
物理恢复，服务和备份分机隔离

手动触发

Save
- 在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令，线上禁止使用
BGSAVE（默认）
- Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
- lastsave 命令可以获取最后一次成功执行快照的时间

1.4 优势和劣势

优势：

适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性要求不高
RDB 文件在内存中的加载速度比AOF快得多

劣势：

在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

1.5 其他

1. 如何检查修复dump.rdb文件

2. 哪些情况会触发RDB快照

配置文件中默认的快照配置
手动 save/bgsave 命令
执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
执行 shutdown 且没有设置开启 AOF 持久化
主从复制时，主节点自动触发

3. 如何禁用快照

动态所有停止 RDB 保存规则的方法命令(一般不用): redis-cli config set save “”
快照禁用

4. RDB优化配置项详解

🥐2. AOF（Append Only File）

2.1 什么是AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF的
- 开启AOF 功能需要设置配置： appendonly yes

2.2 AOF 持久化工作流程

2.3 AOF 缓冲区三种写回策略

三种写回策略

always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
no 操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

2.4 AOF 启动/恢复/修复

1. 启动

步骤：

a. 如何开启AOF

在redis.conf文件中进行修改

b. 使用默认写回策略，每秒钟

c. aof文件-保存路径

Redis 6 AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
Redis 7 作了改变 dir/appendirname

d. aof文件-保存名称

Redis 6 有且只有一个
Redis 7 三个文件：base基本文件、incr增量文件、manifest清单文件

3. 正常恢复

恢复1：重启redis然后重新加载，结果OK
恢复2：
- 写入数据进redis，然后flushdb+shutdown服务器
- 新生成了dump和aof
- 备份新生成的aof.bak，然后删除dump/aof
- 再看恢复B重启redis然后重新加载
- 停止服务器，拿出我们的备份修改后再重新启动服务器。

4. 异常恢复

在网络闪断时，aof文件写了错误的指令，使用异常修复命令： redis-check-aof --fix 进行修复

2.5 优劣势

优势

更好的保护数据不丢失、性能高、可做紧急恢复

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

2.6 AOF重写机制的自动触发和手动触发

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

自动触发

满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

手动触发

客户端向服务器发送 bgrewriteaof 命令

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

AOF文件重写触发机制:通过 redis.conf配置文件中的auto-aof-rewrite-percentage:默认值为100，以及auto-aof-rewritemin-size: 64mb配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

2.7 AOF重写原理

在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

2.8 AOF 优化配置项详解

🥐3. RDB - AOF混合持久化

同时开启两种持久化方式

当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
- 那要不要只使用AOF呢
  - 安特雷兹建议不要
  - 因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段

1 开启混合方式设置

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

2 RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

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