Redis持久化详解（一）：RDB快照机制深度解析

一、引言

在服务器重启或宕机时，内存中的数据会瞬间消失。Redis作为一款高性能的内存数据库，Redis通过持久化机制保证数据安全不丢失的。

Redis提供了两种主流的持久化方案：

• RDB：定期保存Redis内存数据
• AOF：记录每次增删查改的操作

本文将深入探讨RDB持久化的原理、配置、优缺点以及应用场景，下文将详细讲解AOF持久化

二、RDB持久化：数据快照

1. 工作原理

RDB通过创建某个时间点的数据快照来实现持久化。它就像给数据库拍了一张照片，将当前内存中的所有数据保存到磁盘上的一个二进制文件中。

核心机制：

内存数据（时刻T） → 生成快照 → 保存为dump.rdb文件

2. 触发方式

RDB提供了三种触发保存快照的方式：

方式一：配置文件自动触发（最常用）

redis.conf的配置文件在etc/redis/下

# redis.conf 配置示例 save 900 1 # 900秒内至少有1个key被修改，则触发保存 save 300 10 # 300秒内至少有10个key被修改，则触发保存 save 60 10000 # 60秒内至少有10000个key被修改，则触发保存 # 其他相关配置 dbfilename dump.rdb # RDB文件名 dir ./ # 保存目录 rdbcompression yes # 是否压缩（LZF算法） rdbchecksum yes # 是否进行CRC64校验 stop-writes-on-bgsave-error yes # bgsave出错时停止写入

方式二：手动执行SAVE命令（不推荐）

重要警告：SAVE命令会阻塞所有客户端请求！

SAVE命令会让当前Redis服务器进入备份操作，期间所有客户端的请求全部阻塞。慎重使用SAVE命令！

可能导致的严重后果：

1. 应用程序无法从Redis获取数据
2. 大量请求转向MySQL数据库
3. MySQL服务器压力激增，可能导致宕机
4. 整个系统服务不可用
5. 年终奖可能就泡汤了！

方式三：手动执行BGSAVE命令（推荐）

1. 接收命令：Redis主进程接收到bgsave命令。
2. 检查前置条件：主进程先检查是否已有正在运行的bgsave子进程，若有则直接返回失败（避免重复写 RDB 文件）；若没有则继续。
3. 创建子进程：主进程调用fork()系统调用创建一个子进程，此时会发生写时拷贝。
4. 主进程恢复服务：fork 完成后，主进程返回Background saving started,继续处理客户端请求，无阻塞。
5. 子进程写 RDB 文件：子进程遍历 fork 时刻的内存数据，将其序列化后写入临时 RDB 文件
6. 替换旧 RDB 文件：子进程写完临时文件后，用临时文件替换掉旧的 RDB 文件。
7. 通知主进程完成：子进程退出，并通过信号告知主进程持久化完成；主进程更新持久化状态（如记录日志等)。

3. RDB执行流程

4. 优缺点分析

优点：

• 性能高：恢复大数据集时速度比AOF快
• 文件紧凑：二进制格式，适合备份和灾难恢复
• 最大化Redis性能：父进程无需磁盘I/O操作

缺点：

• 可能丢失数据：两次快照之间的数据无法恢复
• fork可能阻塞：数据量过大时，fork子进程可能耗时较长
• 版本兼容性：不同版本的RDB文件格式可能不兼容

三、应用场景

适合使用RDB的场景：

1. 数据备份：定期全量备份，便于灾难恢复
2. 快速重启恢复：大数据集需要快速恢复服务
3. 主从复制：初始化从节点时使用RDB文件
4. 允许数据丢失：缓存场景，数据可以从源头重建

四、总结

RDB持久化是Redis提供的一种简单高效的数据持久化方案。它通过快照机制在特定时间点保存完整的数据集到磁盘，具有恢复速度快、文件紧凑、对性能影响小等优点。

关键要点：

1. 三种触发方式：自动配置、SAVE（阻塞）、BGSAVE（非阻塞）
2. 核心机制：fork子进程 + 写时复制
3. 适用场景：允许少量数据丢失，追求快速恢复
4. 注意事项：大数据集时fork可能阻塞，写操作多时可能有内存压力

下面是我的思维导图，仅供参考：

结语：

以上就是我分享的C++四大类型转换关键字的全部内容了，希望对大家有些帮助，也希望与一样喜欢编程的朋友们共进步

谢谢观看

如果觉得还阔以的话，三连一下，以后会持续更新的，我会加油的

祝大家早安午安晚安