Redis 持久化
- 一、RDB 持久化
- 1.优点:
- 2.缺点:
- 3.实现方式:
- 二、AOF 持久化
- 1.优点:
- 2.缺点:
- 3.实现方式:
- 4.重写机制
- 5.重写流程:
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