总体介绍

• 官网地址：https://redis.io/docs/manual/persistence/

• 持久化双雄：
  • RDB（Redis DataBase）：RDB 是 Redis 默认的持久化方式，它通过生成数据集的快照（snapshot）来保存数据。RDB 文件是一个经过压缩的二进制文件，包含了某个时间点 Redis 数据库中的所有数据。
  • AOF（Append Only File）：AOF 持久化通过记录每个写操作来保存数据。AOF 文件是一个追加写入的日志文件，记录了 Redis 执行的所有写命令。在 Redis 重启时，可以通过重新执行 AOF 文件中的命令来恢复数据。

RDB（Redis DataBase）

官网介绍

• RDB (Redis 数据库)：RDB 持久化以指定的时间间隔执行数据集的时间点快照。

• 在指定的时间间隔，执行数据集的时间点快照。
• 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
• 这个快照文件就称为 RDB 文件(dump.rdb)，其中，RDB 就是 Redis DataBase 的缩写。
• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 snapshot 内存快照，它恢复时再将硬盘快照文件直接读回到内存里。
• Redis 的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端。
• RDB 保存的是 dump.rdb 文件。

案例演示

• RDB 保存到磁盘的文件叫 dump.rdb

• Redis 6.0.16 及以下：

• Redis 6.2 以及 Redis 7.0.0：

• 操作步骤：
  
• 自动触发：
• Redis7 版本，按照 redis.conf 里配置的 save <seconds> <changes>
• 本次案例5秒2次修改，save 5 2 的意思是，如果在 5 秒内发生了 2 次写操作（如 SET 或 DEL），则会触发 RDB 保存。在 5 秒内发生至少 2 次修改，就会触发保存快照。如果在 5 秒内发生了 3 次修改，它满足了这个条件，因此快照会被保存。即使超过了 2 次修改，只要满足时间窗口和修改次数的条件（这里是 5 秒内 2 次修改），快照就会触发。

• 修改 dump.rdb 文件的保存路径

• 修改 dump.rdb 文件名称

• 触发备份
• 第一种情况，5 秒内保存 2 次

• 第二种情况，两次保存间隔超过5秒

• Redis 启动或者 RDB 快照完成，开始计时，期间 Redis 会记录发生写操作的次数。超过了 <seconds> 后，Redis 会统计这段时间里达到修改次数，满足 <changes> 次，会自动触发，每个时间间隔内只会触发一次

• 我看推测配置文件注释描述的应该是距离上次更新超过了 <seconds> 后，Redis 会统计这段时间里达到修改次数，如果满足 <changes> 次数，会自动触发

• 如何恢复：

  • 将备份文件(dump.rdb)移动到 Redis 安装目录并启动服务即可
  • shutdown 命令模拟服务器宕机时，最后那次关机 redis 马上会把当前的快照保存一次，保证跟上一次一致，尽量使其最新
  • 备份成功后故意用 flushdb 清空 redis，看看是否可以恢复数据？执行 flushall/flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
  • 物理恢复，一定要将服务产生的有数据的 RDB 文件备份一份，然后分机隔离，避免生产上物理损坏后备份文件也挂了

• 手动触发：使用 save 或者 bgsave 命令

• redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave

• 生产上只允许用 bgsave 绝对不允许用 save

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

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

• Redis 会使用 bgsave 对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

• fork 是什么？ 在 Linux 程序中，fork() 会产生一个和父进程完全相同的子进程，但子进程在此后会 exec 系统调用，处于效率考虑，尽量避免膨胀，不要太多

• LASTSAVE：可以通过lastsave命令获取最后一次成功执行快照的时间

优势

• 官网说明：

• RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份。例如，您可能希望在最近的 24 小时内每小时归档一次 RDB 文件，并在 30 天内每天保存一个 RDB 快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。

• RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或 Amazon S3 (可能已加密）的压缩文件。

• RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘 I/О 或类似操作。

• 与 AOF 相比，RDB 允许使用大数据集更快地重启。

• 在副本上，RDB 支持重启和故障转移后的部分重新同步。

• 小总结：

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

劣势

• 官网说明：

• 如果您需要在 Redis 停止工作时（例如断电后）将数据丢失的可能性降到最低，那么 RDB 并不好。您可以配置生成 RDB 的不同保存点（例如，在对数据集至少 5 分钟和 100 次写入之后，您可以有多个保存点)。但是，您通常会每五分钟或更长时间创建一次 RDB 快照，因此，如果 Redis 由于任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新分钟的数据。

• RDB 需要经常 fork() 以便使用子进程在磁盘上持久化。如果数据集很大，fork() 可能会很耗时，并且如果数据集很大并且 CPU 性能不是很好，可能会导致 Redis 停止为客户端服务几毫秒甚至一秒钟。AOF 也需要 fork() 但频率较低，您可以调整要重写日志的频率，而不需要对持久性进行任何权衡。

• 小总结：

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

• 模拟数据丢失案例：

  • 正常录入数据
  • kill -9 故意模拟意外宕机
  • redis 重启恢复，查看数据是否丢失

如何检查修复 dump.rdb 文件

• 进入到 redis 安装目录，执行 redis-check-rdb 命令 redis-check-rdb ./redisconfig/dump.rdb

哪些情况下会触发 RDB 快照

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

如何禁用快照

• 第一种方法：动态所有停止 RDB 保存规则的方法：redis-cli config set value ""
• 第二种方法：手动修改配置文件，把注释打开

RDB 优化配置项详解

• 配置文件 SNAPSHOTTING 模块：
  • save <seconds> <changes>：配置快照保存条件
  • dir：配置快照保存目录地址
  • dbfilename：配置快照的文件名
  • stop-writes-on-bgsave-error：默认 yes，如果配置成 no，表示不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保 redis 继续接受新的请求
  • rdbcompression：默认 yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis 会采用 LZF 算法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能
  • rdbchecksum：默认 yes，在存储快照后，还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加大约 10% 的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
  • rdb-del-sync-files：在没有持久化的情况下删除复制中使用的RDB文件。默认情况下 no，此选项是禁用的。

小总结

AOF（Append Only File）

官网介绍

是什么

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

能干嘛

• AOF 保存的是 appendonly.aof 文件

AOF 持久化工作流程

1. Client 作为命令的来源，会有多个源头以及源源不断的请求命令。

2. 在这些命令到达 Redis Server 以后并不是直接写入 AOF 文件，会将其这些命令先放入 AOF 缓存中进行保存。这里的 AOF 缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘 IO 操作。

3. AOF 缓冲会根据 AOF 缓冲区同步文件的三种写回策略将命令写入磁盘上的 AOF 文件。

4. 随着写入 AOF 内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称 AOF 重写)，从而起到 AOF 文件压缩的目的。

5. 当 Redis Server 服务器重启的时候会对 AOF 文件载入数据。

AOF 缓冲区三种写回策略

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

• everysec：每秒写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔 1 秒把缓冲区中的内容写入到磁盘

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

• 三种写回策略小总结 update

AOF 配置/启动/修复/恢复案例演示和说明

• 配置文件说明 (6 VS 7)
• 如何开启 AOF？

• 使用默认写回策略，everysec

• AOF 文件的保存路径：
• redis 6 及以前，AOF 保存文件的位置和 RDB 保存文件的位置一样，都是通过 redis.conf 配置文件的 dir 配置

• redis 7 最新

• AOF 文件的保存名称：
• redis 6 及以前，有且仅有一个

• redis 7 Multi Part AOF 的设计：从 1 个文件到 3 个文件

• MP-AOF 实现

• 顾名思义，MP-AOF 就是将原来的单个 AOF 文件拆分成多个 AOF 文件。在 MP-AOF 中，我们将 AOF 分为三种类型, 分别为:

  • BASE：表示基础 AOF，它一般由子进程通过重写产生，该文件最多只有一个。base 文件是 AOF 的完整快照，包含某一时刻前所有数据的写入操作。在 AOF 重写（BGREWRITEAOF）时生成，替代旧的 AOF 文件。文件较大，但数据完整，适合作为恢复的基础。
  • INCR：表示增量 AOF，它一般会在 AOFRW 开始执行时被创建，该文件可能存在多个。incr 文件记录 base 文件生成后的增量写入操作。每次写入操作都会追加到 incr 文件。文件较小，仅包含增量数据，与 base 文件结合使用以保持数据完整性。
  • HISTORY：表示历史 AOF，它由 BASE 和 INCR AOF 变化而来，每次 AOFRW 成功完成时，本次 AOFRW 之前对应的 BASE 和 INCR AOF 都将变为 HISTORY，HISTORY 类型的 AOF 会被 Redis 自动删除。

• 为了管理这些 AOF 文件，我们引入了一个 manifest (清单)文件来跟踪、管理这些 AOF。manifest 文件记录 base 和 incr 文件的元数据及其关系，确保 Redis 重启时能正确加载这些文件。同时，为了便于 AOF 备份和拷贝，我们将所有的 AOF 文件和 manifest 文件放入一个单独的文件目录中，目录名 appenddirname 配置(Redis 7.0 新增配置项)决定。

• Redis 7.0 config 中对应的配置项

• 正常恢复：

1. 修改默认的 appendonly no，改为 yes
2. 写操作继续，生成 aof 文件到指定目录（然后将 appendonly 文件备份，使用 flushdb+shutdown 服务器来模拟 redis 宕机数据丢失，删除生成的新 aof 文件，将备份文件恢复）
3. 恢复：重启 redis 然后重新加载，结果 OK，将数据重新写入到了 redis

• 在 Redis 中，如果同时存在 dump.rdb 文件和 AOF 文件，Redis 在启动时会按照一定的优先级决定使用哪个文件进行数据恢复，不会发生冲突。

• Redis 在启动时会按照以下顺序检查持久化文件：

  • AOF 文件（如果启用）：Redis 会优先使用 AOF 文件进行数据恢复，因为 AOF 文件通常包含更完整的数据（记录所有写操作）。AOF 文件的数据恢复是通过重新执行 AOF 文件中的命令来实现的。
  • RDB 文件（如果 AOF 文件不存在或未启用）：如果 AOF 文件不存在或未启用 AOF 持久化，Redis 会尝试加载 dump.rdb 文件。RDB 文件是一个快照文件，恢复速度较快，但可能丢失最后一次快照之后的写操作。

• Redis 的设计确保了 AOF 文件和 RDB 文件不会同时用于恢复。如果 AOF 文件存在，Redis 会优先使用 AOF 文件，而忽略 RDB 文件。如果 AOF 文件不存在或损坏，Redis 会回退到使用 RDB 文件。

• AOF 文件通常比 RDB 文件更可靠：AOF 文件记录了所有写操作，可以保证数据的完整性（除非 AOF 文件损坏）。RDB 文件是某一时刻的快照，可能会丢失最后一次快照之后的写操作。

• AOF 文件恢复速度较慢：AOF 文件是通过重放命令来恢复数据的，如果文件较大，恢复时间会较长。RDB 文件恢复速度较快，因为它是直接加载内存的快照。

• 异常恢复：可能存在每一秒钟写入一次，但是内容才写了一小半，没有写完整，突然 redis 挂了导致 AOF 文件错误

1. 故意胡乱改动正常的 AOF 文件，模拟网络闪断文件写入 error 不完整等其他异常情况

2. 重启 Redis 之后就会进行 AOF 文件的载入，发现启动都不行

3. 异常修复命令：redis-check-aof --fix 进行修复

   • 检查 AOF 文件：验证文件格式是否正确，是否存在损坏或不完整的命令。这会检查 AOF 文件并报告问题，但不会修改文件。
   • 修复 AOF 文件：通过 --fix 参数，工具可以尝试修复损坏的部分，删除无效或损坏的命令。工具会尝试修复文件，删除无效命令，修复后的内容会写入新文件，并在原文件名后加上 .fixed 后缀。
   • 如果启用了 --fix 参数，工具会尝试修复检测到的错误：
     • 删除无效命令：如果某条命令无法解析或格式错误，工具会直接跳过并删除该命令。
     • 截断文件：如果文件末尾不完整（例如最后一条命令只写了一半），工具会截断文件，删除不完整的部分。
     • 保留有效命令：所有能够正确解析的命令会被保留，并写入一个新的修复后的文件。

优势

• 更好的保护数据不丢失、性能高、可做紧急恢复
• 使用AOF Redis 更加持久: 您可以有不同的fsync 策略: 根本不fsync、每秒 fsync、每次查询时fsync。使用每秒fsync的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有fsync正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
• AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因) 日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它。
• 当AOF 变得太大时，Redis 能够在后台自动重写AOF。重写是完全安全的，因为当 Redis继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
• AOF以易于理解和解析的格式依次包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您不小心使用孩FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存您的数据集。

劣势

• 相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB。
  • AOF文件更大：AOF（Append-Only File）文件记录了所有写操作的日志，每条写操作都会追加到文件中。随着时间推移，文件会变得非常大，尤其是当数据集频繁更新时。
  • RDB文件更小：RDB（Redis Database）文件是某一时刻的数据快照，只保存当前的数据状态，因此文件通常较小。
  • 恢复速度：AOF文件恢复时需要逐条执行写操作，而RDB文件只需加载快照，因此AOF的恢复速度通常比RDB慢。
• AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同
• AOF文件通常比相同数据集的等效 RDB 文件大。
• 根据确切的 fsync策略，AOF可能比 RDB 慢。一般来说，将fsync 设置为每秒性能仍然非常高，并且在禁用 fsync的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB仍然能够提供关于最大延迟的更多保证。

AOF 重写机制

• 一句话：启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。
• 由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大,文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
• 为了解决这个问题，Redis 新增了重写机制，当 AOF 文件的大小超过所设定的峰值时，Redis 就会自动启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。

• 触发机制：自动触发、手动触发
• 官网默认配置：

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

• 手动触发：客户端向服务器发送 bgrewriteaof 命令

• 案例说明：

  • 启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。
  • 举个例子：比如有个 key 开始你 set k1 v1 然后改成 set k1 v2 最后改成 set k1 v3 如果不重写，那么这 3 条语句都在 aof 文件中，内容占空间不说启动的时候都要执行一遍，共计 3 条命令。但是，我们实际效果只需要 set k1 v3 这一条，所以， 开启重写后，只需要保存 set k1 v3 就可以了只需要保留最后一次修改值，相当于给 aof 文件瘦身减肥，性能更好。
  • AOF 重写不仅降低了文件的占用空间，同时更小的 AOF 也可以更快地被 Redis 加载。

• 前期配置准备：

  1. 开启 AOF
  2. 重写峰值修改为 1k
  3. 关闭混合，设置为 no。AOF 持久化单独起作用，需要关闭混合模式，混合模式 aof-use-rdb-preamble 高版本是默认打开的。
  4. 删除之前的全部 aof 和 rdb，清除干扰项

• 自动触发案例01：

  1. 完成上述正确配置，重启 redis 服务器，执行 set k1 v1 查看 aof 文件是否正常

  2. 查看aof三大配置文件：appendonly.aof.1.base.aof；appendonly.aof.1.incr.aof；appendonly.aof.manifest

  3. k1不停的更新值

  4. 重写触发

• 手动触发案例02：客户端向服务器发送 bgrewriteaof 命令

• 结论：

  • 也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
  • AOF 文件重写触发机制:通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage:100，默认值为100，以及 auto-aof-rewrite-min-size: 64mb 配置，也就是说默认 Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64mb 时触发。

• 重写原理

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

AOF 优化配置项详解

• 配置文件 APPEND ONLY MODE 模块

小总结

RDB - AOF 混合持久化

• 官网建议

• RDB VS AOF 可否共存？如果共存听谁的？
• Redis 配置文档解答：RDB 和 AOF 可以共存，且同时存在时会优先加载 AOF 文件

• 数据恢复顺序和加载流程

• 怎么选？用哪个？

  • RDB 持久化方式能够在指定的时间间隔对你的数据进行快照存储。
  • AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以 redis 协议追加保存每次写的操作到文件末尾。

• 同时开启两种持久化方式

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

• 推荐方式：RDB + AOF 混合方式

  1. 开启混合方式设置：设置 aof−use−rdb−preamble 的值为 yes，yes 表示开启，设置为 no 表示禁用
  2. RDB + AOF 的混合方式 ==> 结论：RDB 镜像做全量持久化，AOF 做增量持久化
     • 先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的 RDB 记录。
     • 这样的话，重启服务的时候会从 RDB 和 AOF 两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。
     • 简单来说：混合持久化方式产生的文件一部分是 RDB 格式，一部分是 AOF 格式。==> AOF 包括了 RDB 头部 + AOF 混写

• 混合持久化模式在 AOF 重写时，将当前数据库的状态以 RDB 格式写入 AOF 文件的开头，后续的写操作则以 AOF 格式追加到文件中。这样，AOF 文件就包含了 RDB 和 AOF 两种格式的数据。

  • RDB 部分：保存了重写时刻的完整数据快照，恢复速度快。
  • AOF 部分：记录了重写后的增量操作，保证数据的实时性。

纯缓存模式

• 同时关闭 RDB + AOF，专心做缓存
  • save ""
    • 禁用 RDB
    • 禁用 RDB 持久化模式下，我们仍然可以使用命令save、bgsave 生成 RDB 文件
  • appendonly no
    • 禁用 AOF
    • 禁用 AOF 持久化模式下，我们仍然可以使用命令 bgrewriteaof 生成 AOF 文件