目录
一、前言
在认识Redis的时候，我们就介绍了Redis的架构如下图所示
尽管我们知道Redis是内存数据库，所有数据都默认存储在内存中，但是内存的易失性意味着一旦服务重启或者崩溃，所有的数据都会丢失。
Redis是支持数据持久到磁盘的，这是为了保证 Redis 不是“一次性内存玩具”，而是可靠的数据存储。主要是为了平衡高性能和数据的可靠性。
通过持久化文件，可以在服务重启后快速恢复数据，减少停机时间。且持久化是Redis主从复制、哨兵和集群等高可用机制的基础，从节点以来持久化文件按同步数据。(后面文章讲到)
Redis提供了两种的吃就换方式，分别为RDB(快照)和AOF(追加日志)
二、RDB快照
1、RDB是什么？能干什么？
RDB(Redis Data Base)：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
- 在指定的时间间隔，执行数据集的时间点快照
- 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
- 这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
- 将内存数据全部保存到磁盘dump.rdb文加中
也就是说在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里
Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端Rdb保存的是dump.rdb文件
2、演示
2.1准备工作
第一步先设置配置文件 redis.conf
为了演示我们改为如下，表示5s内进行两次写操作就执行RDB
接着修改dump文件的保存地址，默认在配置文件
将文件存储路径修改成红色方框所示，注意dumpfiles该目录需要手动创建好。
然后shutdown之后重启服务器，使用config get dir命令即可以获取目录
接着修改dump文件名以方便观察演示
2.2备份恢复
自动操作
注意生成的rdb文件是进绝对路径中查找文件，不是相对路径 cd /myredis/dumpfiles
手动操作
- Save
- 在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令， 线上禁止使用
- BGSAVE（默认）
- Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
- lastsave 命令可以获取最后一次成功执行快照的时间
3、 RDB 文件损坏
当 Redis 在启动时无法加载 RDB 文件，或者在持久化过程中出现异常，可能导致 RDB 文件损坏。此时，Redis 可能会拒绝启动或无法正确加载数据。
这时候使用 redis-check-rdb 工具检查 RDB 文件的完整性，并尝试修复。
redis-check-rdb dump.rdb如果工具报告文件损坏，可以尝试使用 --fix 选项进行修复：
redis-check-rdb --fix dump.rdb
4、RDB快照触发
下面这些情况都会触发RDB
- 配置文件中默认的快照配置
- 手动 save/bgsave 命令
- 执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
- 执行 shutdown 且没有设置开启 AOF 持久化
- 主从复制时，主节点自动触发
5、禁用RDB快照
还是在配置文件里
save ""
6、优缺点
- 优势
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB 文件在内存中的加载速度比AOF快得多
- 劣势
- 在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
- 内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
- RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑
7、优化配置项
忽略失败
压缩功能
提升性能
是否删除复制过程中使用的 RDB 文件
三、AOF
1、AOF是什么？能干什么？
AOF（Append Only File）是 Redis 提供的另一种持久化机制，通过记录所有写操作命令（如 SET、HSET、LPUSH 等）到日志文件，来实现数据持久化，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。与 RDB（快照）不同，AOF 不是保存数据的最终状态，而是保存数据的变更过程。
AOF 文件是一个 纯文本文件，内容是 Redis 协议格式的命令序列。
- 默认情况下，redis是没有开启AOF的
- 开启AOF 功能需要设置配置 ： appendonly yes
2、AOF持久化工作流程
3、AOF 缓冲区三种写回策略
- always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
- everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
- no 操作系统控制协会，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
对比如下
| 配置项 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响较大 |
| Everysec | 每秒写回 | 性能适中 | 宕机时丢失 1 秒内的数据 |
| No | 操作系统控制的写回 | 性能好 | 宕机时丢失数据较多 |
4、AOF配置、启动、修复、恢复
开启AOF
AOF文件 --保存路径
# 为了方便，Redis 将所有持久性只追加文件存储在专用目录中。
# 目录。目录的名称由 appenddirname 配置参数决定。
# 配置参数。AOF文件 --保存名称
MP-AOF（Multi-Part AOF）是 Redis 中一种改进的AOF持久化机制，它将单一的AOF文件拆分成多个文件以提高性能和管理效率。
BASE (基础AOF):
- 由子进程通过重写操作生成。
- 每个Redis实例最多只有一个BASE文件。
- 它代表了数据库的一个完整快照。
INCR (增量AOF):
- 在AOF重写(AOFRW)开始时创建。
- 可能存在多个INCR文件，每个文件记录了自上次重写以来的命令变化。
HISTORY (历史AOF):
- 当AOFRW成功完成后，之前的BASE和INCR文件会变为HISTORY类型。
- HISTORY类型的AOF文件会被Redis自动删除，以保持存储空间的有效利用。
为了更好地管理和跟踪这些不同类型的AOF文件，Redis引入了一个manifest（清单）文件。这个文件记录了所有AOF文件的信息，包括它们的类型、位置和状态等。此外，所有的AOF文件和manifest文件都被放置在一个单独的目录中，该目录的名称由appenddirname配置项决定。
异常修复
与RDB一样，他也有修复功能
在网络闪断时，aof文件写了错误的指令，使用
异常修复命令 ： redis-check-aof --fix 进行修复
5、AOF重写机制
AOF（Append Only File）重写机制是 Redis 中用于优化 AOF 持久化文件大小和性能的重要功能。当 AOF 文件变得过大时，Redis 可以通过重写机制生成一个新的、更紧凑的 AOF 文件，从而减少磁盘占用并提高恢复速度。
开启重写机制
需要注意的是，上面的两条是同时满足的情况下才会重写。
自动触发
- 满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
- 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
手动触发
- 客户端向服务器发送 bgrewriteaof 命令
也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF 文件重写触发机制：通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage，默认值为 100，以及 auto-aof-rewrite-min-size: 64mb 配置，也就是说默认 Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。
举个例子来说，比如 set k1 v1之后又k1做了修改，那么重写就只会记录修改的命令。
重写原理
1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
6、AOF 优化配置项
| 配置指令 | 配置含义 | 配置示例 |
|---|---|---|
| appendonly | 是否开启 aof | appendonly yes |
| appendfilename | 文件名称 | appendfilename "appendonly.aof" |
| appendfsync | 同步方式 | everysec/always/no |
| no-appendfsync-on-rewrite | aof 重写期间是否同步 | no-appendfsync-on-rewrite no |
| auto-aof-rewrite-percentage auto-aof-rewrite-min-size |
重写触发配置、文件重写策略 | auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb |
四、RDB与AOF共存
在 Redis 中，RDB 和 AOF 可以 同时启用，形成 “双重持久化” 机制。此时 Redis 会根据两者的特性协同工作，优先保证数据安全性，同时兼顾性能和恢复速度。
1、持久化过程
互不干扰，独立执行
- RDB：按
save规则（如900 1）或手动BGSAVE生成快照，与 AOF 日志无直接关联。 - AOF：按
appendfsync策略（如everysec）记录写命令，独立追加到appendonly.aof文件。 - 文件存储：两者生成的文件独立（如
dump.rdb和appendonly.aof），不会互相覆盖。
2、数据恢复
当 Redis 重启时，若同时存在 RDB 和 AOF 文件，Redis 会优先加载 AOF 文件恢复数据，原因是：AOF 数据更完整：AOF 记录最近的所有写命令（最多丢失 1 秒数据），而 RDB 可能丢失最后一次快照后的大量数据。
那要不要只使用AOF呢？安特雷兹建议不要，因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段。
3、纯缓存模式
当 Redis 仅作为 纯缓存 使用（无需持久化数据，允许服务重启后数据全部丢失），可以同时关闭 RDB 和 AOF 持久化，以最大限度提升性能（避免磁盘 I/O 开销）
- save “”
- 禁用rdb
- 禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
- appendonly no
- 禁用aof
- 禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件