Redis 持久化
- [一、RDB 持久化](#一、RDB 持久化)
- [二、AOF 持久化](#二、AOF 持久化)
Redis 提供了两种主要的持久化方式：RDB 和 AOF
一、RDB 持久化
RDB（Redis Database Backup file）是通过快照（内存中数据在某一时刻的状态记录）的方式将内存中的数据以二进制格式保存到磁盘上。
1.优点：
- 数据恢复速度快：在需要恢复大量数据时，RDB 的恢复速度通常比 AOF 快。
- 文件体积小：由于数据以二进制格式压缩存储，RDB 文件通常比 AOF 文件小。
- 性能影响小：使用 bgsave 命令进行持久化时，主进程不会阻塞，性能影响较小。
2.缺点：
- 数据丢失风险：由于 RDB 是定时快照，两次快照之间的数据变动可能会丢失。
- 资源消耗：在执行 bgsave 时，需要创建子进程，这可能会消耗较多的内存和CPU资源。
3.实现方式：
RDB 通过定时执行 bgsave 命令来创建快照。
快照过程是通过创建一个子进程来完成的，子进程复制主进程的内存数据并写入RDB文件。
这种方式利用了写时复制技术，确保主进程不会被阻塞。
二、AOF 持久化
AOF（Append Only File）通过记录每次写操作命令的方式来实现持久化。
1.优点：
- 数据完整性高：由于记录了每次写操作，AOF 文件可以提供更高的数据完整性。
- 灵活性高：可以通过配置不同的同步策略来平衡性能和数据的完整性。
2.缺点：
- 文件体积大：由于记录了每次写操作，AOF 文件通常比 RDB 文件大。
- 性能影响：在写入磁盘时可能会影响性能，尤其是在高负载情况下。
3.实现方式：
AOF 通过记录每次写操作命令来实现持久化。
可以通过配置不同的 appendfsync 选项来控制命令写入磁盘的频率，从而平衡性能和数据完整性。
4.重写机制
AOF 文件的大小达到某个阈值时，会将其中指令进行压缩。(如果有对于某个key多次的变更指令，则仅保留最新的数据指令)。
5.重写流程：
- 手动执行 bgrewriteaof 命令触发重写，判断是否当前有 bgfsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行；
- 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；
- 子进程遍历 redis 内存中的数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和aof_rewrite_buf 重写缓冲区保证原 AOF 文件完整性以及新 AOF 文件生成期间的新的数据修改动作不会丢失
- 子进程写完新的 AOF 文件后，向主进程发送信号，父进程更新统计信息
- 主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件
- 使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写
参考：https://blog.csdn.net/Zyw907155124/article/details/135404474