0 前言
什么是持久化
redis操作都是在内存中，如果出现宕机的话，数据将不复存在，所以持久化是将内存中的数据刷盘到磁盘中，redis可以提供RDB和AOF将数据写入磁盘中。
一 持久化技术
本章节将介绍持久化RDB和AOF两个技术，以及其混合技术。
Redis 的 RDB（Redis DataBase）持久化技术是一种将 Redis 在内存中的数据保存到磁盘上的持久化方式，以指定的时间间隔执行数据集的时间点快照。
其原理如下：
快照生成： RDB 会将 Redis 某一时刻的内存数据以快照的形式保存到磁盘上，生成一个 dump.rdb 文件。该文件是一个经过压缩的二进制文件，默认存储在当前目录。
** 子进程操作：** 当满足触发条件时，Redis 父进程会 fork 出一个子进程来进行 RDB 文件的创建和写入。子进程会继承父进程的内存数据，然后将这些数据写入到临时文件中。在这个过程中，父进程可以继续处理客户端的请求，不会因为持久化操作而被阻塞。当子进程完成写操作后，会用新生成的临时文件替换旧的 RDB 文件。
触发方式：
手动触发：
- SAVE 命令：由主进程直接进行快照操作，在生成 RDB 文件期间，Redis 服务器会阻塞，无法处理其他客户端请求，因此一般线上环境不建议使用。
- BGSAVE 命令：通过 fork 子进程来进行快照操作，子进程负责创建 RDB 文件，而父进程则可以继续处理请求。此命令执行过程中只有 fork 子进程时会短暂阻塞服务器，对客户端请求的影响较小。
自动触发： - 配置文件参数：在 redis.conf 配置文件中，可以通过设置 save m n 参数来指定自动触发 RDB 持久化的条件，其中 m 表示时间间隔，n 表示在该时间间隔内数据的修改次数。例如 save 900 1 表示在 900 秒内如果至少有 1 个 key 发生变化，则执行 bg save。其中默认的时间与频次如下：
举一个管网中的例子，刷新RDB的时间间隔，以及时间间隔内发生的修改：
其中dump文件的路径需要指定：
dir /myredis/dumpfiles
- 主从复制触发：在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行 bgsave 命令，并将 rdb 文件发送给从节点。
- 执行特定命令触发：执行 shutdown 命令关闭 Redis 时，也会触发 RDB 持久化。
那些情况触发RDB
禁止使用快照
禁用快照：
RDB参数配置的优化
redis7时，RDB保存时间做了调整，将持久化文件RDB的保存规则发生了改变，尤其是时间记录频率变化。
备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器上，必须分开各自存储，以防止生产机物理损坏后备份也挂了。*
RDB和AOF之间的优缺点
RDB的优点：
1.性能最大化：在开始持久化时，Redis 只需 fork 出子进程，之后由子进程完成持久化工作，避免了服务进程执行 IO 操作，大大提高了性能。
2.适合大规模数据备份：由于 RDB 文件是一个完整的数据库快照，非常适合进行大规模的数据备份，可以将 RDB 文件压缩后转移到其他存储介质上。
3.启动加载速度快：相比于 AOF 机制，RDB 文件在恢复数据时速度更快，因为只需要加载整个数据集即可。
RDB的缺点：
1.数据丢失风险：如果系统在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2.服务器阻塞问题：当数据集较大时，fork 子进程可能会导致整个服务器停止服务几百毫秒，甚至 1 秒钟。
3. 版本兼容性问题：RDB 文件使用特定的二进制格式保存，Redis 版本演进过程中可能会出现多个 RDB 版本，存在一定的版本兼容性风险。
二、AOF持久化技术
AOF持久化将每个写操作（如SET、DEL等）以追加的方式写入一个文件（AOF文件）。Redis重启时，会读取AOF文件并重新执行这些命令，从而恢复数据。
设置AOF持久化，需要在redis.conf文件中配置
appendonly yes
2.1 AOF的工作流程
1.Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2.在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3.AOF缓冲会根据AOF缓冲区同步文件的 三种写回策将命令写入磁盘上的AOF文件。
4.随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5.当Redis Server服务器重启的时候会从AOF文件载入数据。
r
2.1.1 Redis提供了三种AOF文件同步策略
always：每次写操作都同步到磁盘，数据安全性最高，但性能最差。
everysec：每秒同步一次，平衡了性能和数据安全。
no：由操作系统决定同步时机，性能最好，但数据安全性最低。
2.1.2 redis7新特性
文件的保存路径
redis6，AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
redis7，最终路径。比如下图所示，AOF会在myredis/appendonlydir生成.aof文件。
redis有且仅有一个文件。
redis7的aof文件，一共有1到3个，分别是base基本文件，incr增量文件，manifest清单文件。
增量文件中不符合语法规则的数据进行清空，可使用一下命令。
2.2 AOP的优缺点
2.2.1 优势
- 使用 AOF Redis 更加持久:您可以有不同的 fsync 策略:根本不fsync、每秒 fsync、每次查询时 fsync。使用每秒 fsync 的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
- AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因)日志以驾一半的命令结尾，redis-check-aof 工具也能够轻松修复它
- 当 AOF 变得太大时，Redis 能够在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
- AOF 以易于理解和解析的格式依次包含所有操作的日志。您甚至可以轻松导出 AOF 文件。例如，即使您不小心使用该FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存您的数据集.
2.2.2 缺点
- AOF 文件通常比相同数据集的等效 RDB 文件大。
- 根据确切的 fsync 策略，AOF 可能比 RDB 慢。一般来说，将 fsync 设置为每秒性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB 仍然能够提供关于最大延迟的更多保证。
2.3 AOF重写机制
随着时间推移，AOF文件会变得庞大，可能包含冗余命令。Redis提供了AOF重写机制，通过创建一个新的AOF文件来移除冗余命令，从而减小文件大小并加快恢复速度。
1.手动触发：通过执行BGREWRITEAOF命令，Redis会在后台启动AOF重写过程。
2.自动触发：Redis会根据配置的规则自动触发AOF重写。相关配置参数如下：
- auto-aof-rewrite-percentage：当前AOF文件大小比上次重写后文件大小的增长百分比。
- auto-aof-rewrite-min-size：AOF文件的最小大小，只有超过该大小才会触发重写。
默认配置为：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这意味着当AOF文件大小比上次重写后的大小增加100%（即翻倍），并且文件大小至少为64MB时，Redis会自动触发AOF重写。
重写机制演示案例，其中基础文件同一个可以只记录最新的值，不记录历史值，base文件相当于瘦身aof文件。
2.4. AOF重写的执行过程
AOF重写是通过子进程完成的，不会阻塞主进程的正常运行。具体过程如下：
1.主进程fork子进程：主进程会fork一个子进程来执行AOF重写任务。
2.子进程生成新AOF文件：子进程根据当前数据库状态生成新的AOF文件。
3.主进程继续处理请求：在子进程重写期间，主进程会继续处理客户端请求，并将新的写操作命令写入AOF缓冲区和AOF重写缓冲区。
4.子进程完成重写：当子进程完成重写后，会通知主进程。
5.主进程处理重写缓冲区：主进程将AOF重写缓冲区中的命令追加到新的AOF文件中。
6.替换旧文件：最后，Redis用新的AOF文件替换旧的AOF文件。
2.5 AOP配置总结
三 RDB-AOF混合持久化
如果同时开启RDB和AOF持久化，重启时只会加载aof文件，不会加载 rdb。
3.1 何选择
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.。
3.1.1 同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。
推荐使用方式：RDB+AOF
3.2 同时关闭RDB和AOF
此模式是纯缓存模式
save “” 禁用RDB，禁用rdb持久化模式下，我们仍可以使用命令save,bgsave生成rdb文件
appendonly no 禁用aof，禁用aof模式下，我们仍可以使用bdwriteaof生成aof文件。
