Redis 持久化操作详解
Redis 实现持久化的时候，具体是按照什么样的策略来实现的呢？
Redis支持两种方式的持久化，一种是RDB方式、另一种是AOF（append-only-file）方式，两种持久化方式可以单独使用其中一种，也可以将这两种方式结合使用。
- RDB(Redis DataBase)：根据指定的规则将内存中的数据定期备份存储在硬盘上，
- AOF(Append Only File)：每次执行命令后将命令本身记录下来，实时备份。
一、RDB 持久化
1.1 RDB 原理
RDB 持久化是通过生成数据快照（Snapshot）的方式，将 Redis 内存中的数据写入到磁盘上的二进制文件中。这个文件被称为 RDB 文件。RDB 文件可以在 Redis 重启时用于恢复数据。
Redis 提供了两种生成 RDB 文件的命令：SAVE 和 BGSAVE。
SAVE命令：在主线程中执行生成 RDB 文件的操作。由于 ，由于和执行操作命令在同一个线程，如果写入 RDB 文件的时间太长，中会阻塞主线程BGSAVE命令：创建一个子进程来生成 RDB 文件，这样可以避免了阻塞主线程的情况
重点介绍一下：BGSAVE的工作流程
Redis的BGSAVEe工作流程是通过创建子进程来实现异步生成快照。在这个过程中，Redis使用了写时复制（copy-on-write）技术，它的核心思想是在主进程发生写操作时，会将相关的内存页复制一份，然后交给子进程使用，而主进程则继续进行正常的读写操作。这样可以保证只有在出现需要变更的数据时才进行数据复制，从而减少额外内存消耗和提高性能。
当执行BGSAVE命令时，Redis会创建一个子进程来执行实际的持久化工作，同时父进程继续处理客户端的其他请求。子进程会将数据写入内存的临时文件中，使用写时复制技术来保证数据的一致性。在生成RDB文件的过程中，只有当发生需要变更的数据时才进行内存页的复制，从而避免内存的额外占用。
1.2 RDB 自动化配置
Redis 可以通过配置文件的选项来实现自动化的 RDB 持久化，
配置文件位置一般：
具体配置如下：
save 900 1
save 300 10
save 60 10000
别看选项名叫 save，实际上执行的是 bgsave 命令，也就是会创建子进程来生成 RDB 快照文件。开启之后，RDB的目录一般默认：/var/lib/redis（可以自行配置的）
只要满足上面条件的任意一个，就会执行 bgsave，它们的意思分别是：
- 900 秒之内，对数据库进行了至少 1 次修改；
- 300 秒之内，对数据库进行了至少 10 次修改；
- 60 秒之内，对数据库进行了至少 10000 次修改。
只要满足以上任一条件，Redis 就会执行一次 BGSAVE 操作。
Redis 的 RDB（Redis Database）快照是全量快照，每次执行时都会将内存中的所有数据记录到磁盘。如果设置频率太高则会让成本变高，负载较重，频繁执行会影响 Redis 的性能，而设置的频率太低则会在服务器故障时导致更多数据丢失。通常，RDB 快照至少设置为每 5 分钟保存一次，以在性能和数据丢失风险之间取得平衡。与 AOF（Append Only File）持久化相比，RDB 快照在故障时可能丢失更多数据，因为 AOF 可以每秒记录操作，减少数据丢失。
如果 Redis 服务器宕机，在使用 RDB 快照时，系统会丢失自上次快照以来的所有数据。例如，如果快照每 5 分钟执行一次，宕机时最多可能会丢失 5 分钟的数据。
1.3 RDB 的优缺点
优点：
- 数据恢复速度快：RDB 文件是紧凑的二进制文件，加载速度很快。
- 占用磁盘空间小：RDB 文件经过压缩，占用的磁盘空间较少。
- 适合大数据恢复：在数据量较大时，RDB 文件的加载速度要比 AOF 快得多。
缺点：
- 数据丢失风险较高：由于 RDB 是定期快照，如果 Redis 在两次快照之间发生故障，所有在此期间的数据修改将会丢失。
- 频繁快照对性能的影响：频繁执行
BGSAVE操作会导致额外的磁盘 I/O 操作和 CPU 资源消耗。
1.4 RDB 快照期间的数据修改
在执行 BGSAVE 过程中，Redis 仍然可以继续处理写操作。这是通过写时复制技术（Copy-On-Write, COW）实现的。当 BGSAVE 命令执行时，Redis 会通过 fork() 创建一个子进程，子进程与主进程共享相同的内存数据。只有在修改数据时，才会将被修改的数据复制一份，从而主进程可以继续处理新的写操作，而子进程可以继续读取原来的数据进行 RDB 快照。
Redis 的 BGSAVE 机制通过创建子进程在后台执行数据快照，有效地减少了创建子进程时的性能损耗，并避免了阻塞主线程。子进程与父进程共享内存数据，使得子进程可以直接读取并写入 RDB 文件，而不会影响主线程的只读操作。然而，一旦主线程需要修改共享数据，就会触发写时复制机制，复制数据副本供主线程修改，而子进程继续使用原始数据进行快照。这意味着在快照过程中主线程的修改不会即时反映到 RDB 文件中，存在数据丢失的风险。此外，极端情况下，频繁的写操作可能导致内存占用翻倍，因此在写操作密集的场景中，需要密切监控内存使用，以防止内存耗尽。总之，bgsave 提供了一种高效的数据持久化方式，但同时也需要谨慎管理内存资源和考虑数据一致性问题。
1.5 RDB 实践示例
在实际应用中，可以通过以下命令和配置来实现 RDB 持久化：
-
在命令行中，手动生成 RDB 快照：
SAVE或
BGSAVE -
配置文件设置自动生成 RDB 快照：
save 900 1 save 300 10 save 60 10000
二、AOF 持久化
2.1 AOF 原理
AOF（Append Only File）持久化通过记录每次写操作的日志来实现数据的持久化。Redis 将每次写操作（例如 SET、INCR 等）记录到 AOF 文件中，当 Redis 重启时，可以通过重放 AOF 文件中的写操作来恢复数据。
AOF 的⼯作流程操作：命令写⼊（append）、⽂件同步（sync）、⽂件重写（rewrite）、重启加载（load）
在 Redis 中 AOF 持久化功能默认是不开启的，需要我们修改 redis.conf 配置文件中的以下参数：
开启之后，所在的位置和RDB的目录一样:/var/lib/redis（可以自行配置的）
AOF 文件是纯文本文件，包含了所有修改 Redis 数据的命令。Redis 提供了三种不同的同步策略来控制 AOF 文件的写入频率：
appendfsync always：每次有数据修改时都同步到 AOF 文件，性能最差但数据最安全。appendfsync everysec：每秒同步一次 AOF 文件，性能和数据安全性之间的折中方案。appendfsync no：由操作系统决定何时同步 AOF 文件，性能最好但数据安全性最差。
| 写回策略 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步写回 | 可靠性高、最大程度保证数据不丢失 | 性能开销大 |
| Everysec | 每秒写回 | 性能适中 | 宕机时会丢失1秒内的数据 |
| No | 由操作系统控制写回 | 性能好 | 宕机时丢失的数据可能会很多 |
2.2 AOF 重写
随着时间的推移，AOF 文件会不断增长，为了避免文件过大，Redis 提供了 AOF 重写机制。AOF 重写通过创建一个新的 AOF 文件，包含相同的数据但体积更小。
AOF 重写是在后台通过创建子进程来完成的，不会阻塞主线程。
重写过程如下：
- 创建一个子进程。
- 子进程读取当前的数据库快照，并将其写入到新的 AOF 文件中。
- 主线程继续记录新的写操作到重写缓冲区中。
- 重写完成后，将重写缓冲区中的写操作追加到新的 AOF 文件中。
- 用新的 AOF 文件替换旧的 AOF 文件。
在Redis执行AOF重写（AOF rewrite）过程中，子进程负责创建新的AOF文件，而父进程则继续处理客户端请求，并将新请求产生的AOF数据写入到缓冲区，随后刷新到原有的AOF文件中。子进程在创建时继承了父进程的内存状态，因此其内存数据反映了父进程fork操作之前的状态。对于fork之后父进程接收的新请求及其对内存的修改，子进程并不知情。为此，父进程额外设置了一个名为aofrewrite_buf的缓冲区，专门用于存放fork之后接收的数据。当子进程完成新AOF文件的写入后，会通过信号通知父进程，父进程随后将aofrewrite_buf缓冲区中的内容追加到新AOF文件中。这一过程完成后，新的AOF文件将取代旧的AOF文件，确保数据的完整性和一致性。
那么是如何让原本的数据但体积更小
重写机制的妙处在于，尽管某个键值对被多条写命令反复修改，最终也只需要根据这个「键值对」当前的最新状态，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这样就减少了 AOF 文件中的命令数量。最后在重写工作完成后，将新的 AOF 文件覆盖现有的 AOF 文件。
2.3 AOF 的优缺点
优点：
- 数据持久性高：AOF 可以记录每个写操作，通过适当的同步策略，几乎可以实现秒级的数据持久性。
- 可读性好：AOF 文件是纯文本文件，可以很方便地查看和编辑。
- 适合频繁写操作：由于 AOF 是记录每次写操作，不会像 RDB 那样生成大文件，因此适合频繁写操作的场景。
缺点：
- 文件体积大：相比 RDB，AOF 文件会更大，因为它记录了所有的写操作。
- 恢复速度较慢：重放 AOF 文件中的写操作来恢复数据，速度比加载 RDB 文件要慢。
2.4 AOF 实践示例
在实际应用中，可以通过修改配置文件：
-
开启 AOF 持久化：
appendonly yes -
配置 AOF 同步策略：
appendfsync everysec -
手动触发 AOF 重写：
BGREWRITEAOF
三、混合持久化
尽管 RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：
- 如果频率太低，两次快照间一旦服务器发生宕机，就可能会比较多的数据丢失；
- 如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。
那有没有什么方法不仅有 RDB 恢复速度快的优点和，又有 AOF 丢失数据少的优点呢？
当然有，那就是将 RDB 和 AOF 合体使用，这个方法是在 Redis 4.0 提出的，该方法叫混合使用 AOF 日志和内存快照，也叫混合持久化。
如果想要开启混合持久化功能，可以在 Redis 配置文件将下面这个配置项设置成 yes：
aof-use-rdb-preamble yes
混合持久化工作在 AOF 日志重写过程。
当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。
