RDB持久化
RDB是Redis的一种快照持久化方式，它将内存中的数据集都写入磁盘，生成一个RDB文件，RDB文件是一个经过压缩的二进制文件（通常叫做数据快照），可以用于备份、迁移和恢复数据。
RDB的优点是快速、紧凑，适合备份和恢复大量数据，但是它的缺点是数据可能会丢失，因为RDB文件只保存了最后一次快照的数据
执行时机
RDB持久化在以下四种情况下会执行：
1. 执行save命令（Redis持久化命令）：
当执行save命令时，Redis会阻塞所有客户端请求，将内存中的数据集快照写入磁盘，生成一个RDB文件。这个过程会阻塞Redis的正常运行（无法响应客户端请求，造成服务中断），保存完成后，Redis会解除阻塞，继续处理客户端请求。
2. 执行bgsave命令（后台持久化命令）：
bgsave命令的执行过程中，Redis会先创建一个子进程，然后父进程继续处理客户端请求，而子进程负责将数据集保存到磁盘。这种方式可以保证Redis的正常响应，不会中断服务。 由于bgsave命令是在后台执行的，所以在执行期间无法立即得知保存的进度和结果,可以通过lastsave命令或者检测RDB文件判断保存情况。
3. Redis停机
当Redis服务停机时，无论是正常关闭还是异常退出，都会触发RDB持久化，Redis会执行一次save命令，将数据集快照写入磁盘。
4. 触发RDB条件
用户可以通过设置配置文件（redis.conf）中的save命令来指定触发RDB持久化的条件，
例如：设定在900秒内至少有1个键被修改，就执行一次bgsave命令（如果是save "" 则表示禁用RDB）
# redis.conf文件
save 900 1
执行原理
bgsave开始时会fork主进程得到子进程（和主进程相同），子进程共享主进程的内存数据，负责将内存中的数据集写入磁盘。
fork命令使用了写时复制（Copy-on-Write）的技术：在主进程执行写操作时，才会真正复制父进程的内存页，而在此之前，子进程与父进程共享相同的内存页，这样可以减少内存的复制开销，提高性能。
AOF持久化
在Redis每次写入操作执行完成后，将该操作以文本的形式追加到AOF文件的末尾，AOF文件是一个文本文件，记录了所有写入操作的历史（也就是记录写操作的命令），可以用于数据恢复。
AOF的执行时机是由Redis自动触发的，由刷盘策略决定。
开启AOF方式方法，修改配置文件redis.conf（不需要关闭RDB，二者可以同时使用）
# redis.conf文件
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF 3种刷盘策略
| 刷盘策略 | 刷盘时机 | 优点 | 缺点 |
| always | 每次写入操作 | 数据安全性最高，几乎不会丢数据 | 性能开销较大 |
| everysec | 每秒刷盘 | 数据安全较高，性能相对较好 | 性能适中 |
| no | 操作系统决定刷盘时机 | 性能开销最小 | 数据安全性较低 |
文件配置
# redis.conf文件（三个选一个）
appendfsync always
# appendfsync everysec
# appendfsync no
二者对比
- RDB是快照形式的持久化方式，将数据集的快照以二进制形式保存在磁盘上，而AOF是将写入操作以追加的方式记录到文件中。
- RDB持久化生成的文件较小，加载速度较快。AOF持久化生成的文件较大，加载速度较慢，但可以提供更好的数据安全性。
- RDB持久化可以定期或手动触发，而AOF持久化可以根据不同的刷盘策略进行配置
- RDB持久化对Redis的读取性能没有影响，因为数据是从磁盘加载到内存中，而AOF持久化在写入性能上可能会有一定影响，因为每次写入操作都需要追加到文件中。
- RDB持久化在故障恢复时速度较快，因为只需加载最近的RDB文件即可，而AOF持久化在故障恢复时可能需要较长时间，因为需要重新执行AOF文件中的所有写入操作。
总结：RDB适合备份和恢复大量数据，加载速度快；AOF提供更好的数据安全性，但文件较大且加载速度较慢。
