1. Redis持久化概述
Redis是内存数据库 ，数据默认存储在内存中，断电或重启后数据会丢失。持久化机制通过将内存数据持久化到磁盘，保证数据的可靠性 和可恢复性。
Redis支持三种持久化方式：
- RDB：快照式持久化，定期生成内存快照
- AOF：日志式持久化，记录所有写命令
- 混合持久化：结合RDB和AOF的优势，Redis 4.0+支持
2. RDB持久化（Redis Database）
2.1 核心定义
RDB是一种快照式持久化 ，通过fork子进程 将内存中的数据以二进制格式写入磁盘文件（默认dump.rdb）。
2.2 实现原理
BGSAVE命令执行流程：
- Redis收到
BGSAVE命令 - 主进程调用
fork()创建子进程（写时复制，仅复制页表，不复制数据） - 子进程遍历内存，生成RDB文件
- 子进程写入完成后，通知主进程
- 主进程替换旧RDB文件
写时复制（Copy-On-Write）机制：
- 子进程创建时，共享主进程的内存页
- 主进程修改数据时，复制被修改的页，子进程仍访问旧页
- 确保子进程生成的RDB文件是创建时刻的快照
2.3 触发机制
手动触发：
SAVE：同步执行，阻塞主进程，不建议生产环境使用BGSAVE：异步执行，通过子进程生成RDB，不阻塞主进程
自动触发 ：
通过配置文件redis.conf的save指令：
ini
# 900秒内有1个键变化，触发BGSAVE
save 900 1
# 300秒内有10个键变化，触发BGSAVE
save 300 10
# 60秒内有10000个键变化，触发BGSAVE
save 60 10000其他触发场景：
FLUSHALL：清空所有数据时，触发RDB生成（空快照）- 主从复制：从节点连接主节点时，主节点执行BGSAVE生成RDB
- 关闭Redis：执行
SHUTDOWN且未开启AOF时，触发BGSAVE
2.4 优缺点
| 优点 | 缺点 |
|---|---|
| 文件小：二进制压缩存储，占用磁盘空间小 | 数据丢失风险大 ：两次快照间的数据可能丢失（如配置save 60 10000，60秒内崩溃会丢失数据） |
| 恢复速度快：直接加载二进制数据到内存，适合大规模数据恢复 | fork开销大：fork子进程时，若内存大，会阻塞主进程（毫秒级到秒级） |
| 适合备份：可作为全量备份，便于跨环境迁移 | 不适合实时持久化：无法保证数据零丢失 |
| 主从复制友好：RDB是主从复制的基础，从节点通过RDB初始化 | 对内存敏感：fork时，若内存使用率高，可能导致OOM或系统swap |
3. AOF持久化（Append Only File）
3.1 核心定义
AOF是一种日志式持久化 ，将所有写命令 以文本格式追加到AOF文件（默认appendonly.aof），重启时通过重放命令恢复数据。
3.2 实现原理
核心流程：
- 命令追加（Append）：写命令追加到AOF缓冲区
- 文件写入（Write）：缓冲区数据写入AOF文件（内核页缓存）
- 文件同步（Sync） ：调用
fsync/fdatasync将页缓存数据刷到磁盘
同步策略 ：
通过配置appendfsync控制，影响安全性 和性能：
| 策略 | 实现 | 数据安全性 | 性能 | 适用场景 |
|---|---|---|---|---|
always |
每个写命令都调用fsync | 最高（零丢失） | 最低（IO开销大） | 对数据安全性要求极高的场景（如金融） |
everysec |
每秒调用一次fsync | 较高（最多丢失1秒数据） | 较好（平衡安全和性能） | 大多数生产环境 |
no |
由操作系统决定何时同步 | 最低（可能丢失大量数据） | 最高（Redis不主动刷盘） | 对数据丢失不敏感的场景 |
3.3 重写机制（AOF Rewrite）
核心问题：AOF文件会持续膨胀（如多次修改同一键，记录所有命令），导致文件过大、恢复速度慢。
重写原理：
- 生成新的AOF文件 ，包含恢复当前数据所需的最小命令集
- 例如：
INCR count执行100次，重写为SET count 100 - 避免记录无效命令（如已删除键的命令）
触发机制：
-
手动触发：
BGREWRITEAOF命令 -
自动触发：通过配置文件控制：
ini# AOF文件大小超过上次重写后100%，且大于64MB时触发 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
重写流程：
- Redis收到
BGREWRITEAOF命令 - 主进程fork子进程
- 子进程遍历内存，生成重写后的AOF文件
- 主进程将新的写命令追加到AOF重写缓冲区
- 子进程写入完成后，通知主进程
- 主进程将AOF重写缓冲区的命令追加到新AOF文件
- 替换旧AOF文件
3.4 优缺点
| 优点 | 缺点 |
|---|---|
| 数据安全性高：可配置为每秒或每次命令同步，丢失数据少 | 文件大：文本格式，占用磁盘空间大（通常是RDB的2-5倍） |
| 可读性强：文本格式，可直接查看或修改命令 | 恢复速度慢：需重放所有命令，大规模数据恢复时间长 |
| 支持增量备份：每次追加命令，适合增量备份 | 写入性能略低：每次写命令都需追加到文件，IO开销大 |
| 自动重写机制：避免文件无限膨胀 | 重写开销大：fork子进程和生成新文件的开销 |
4. 混合持久化（Redis 4.0+）
4.1 核心定义
混合持久化结合了RDB和AOF的优势，AOF文件前半部分是RDB格式 ，后半部分是AOF格式。
4.2 实现原理
配置开启：
ini
# Redis 4.0+开启混合持久化
aof-use-rdb-preamble yes重写流程：
BGREWRITEAOF触发时，先以RDB格式写入AOF文件- 然后将重写期间的新命令以AOF格式追加到文件
AOF文件结构：
[RDB部分] + [AOF部分]4.3 优势
| 优势 | 说明 |
|---|---|
| 恢复速度快：前半部分是RDB格式，加载速度快 | 结合RDB的快速恢复优势 |
| 数据安全性高：后半部分是AOF格式，保证最近数据不丢失 | 结合AOF的高安全性优势 |
| 文件大小适中：RDB部分压缩存储，AOF部分仅记录增量命令 | 避免纯AOF文件过大的问题 |
| 写性能好：与AOF everysec相当，无额外性能开销 | 保持AOF的良好写入性能 |
5. 面试题：RDB与AOF的区别？
| 对比维度 | RDB | AOF |
|---|---|---|
| 持久化方式 | 快照式（定期生成内存镜像） | 日志式（记录所有写命令） |
| 文件格式 | 二进制格式 | 文本格式（Redis协议） |
| 文件大小 | 小（压缩存储） | 大（记录所有命令） |
| 恢复速度 | 快（直接加载二进制数据） | 慢（重放所有命令） |
| 数据安全性 | 低（可能丢失两次快照间的数据） | 高（可配置为每秒或每次命令同步） |
| 写入性能 | 高（仅fork时开销大） | 略低（每次写命令需追加文件） |
| 触发机制 | 手动（SAVE/BGSAVE）+ 自动（配置save条件） | 实时追加 + 重写（BGREWRITEAOF） |
| 适用场景 | 大规模数据恢复、主从复制、全量备份 | 对数据安全性要求高的场景 |
| 备份策略 | 适合全量备份（文件小，便于存储） | 适合增量备份（可追加） |
| 重写机制 | 无（直接覆盖旧文件） | 有（BGREWRITEAOF，压缩命令） |
6. 持久化策略选择
| 场景 | 推荐策略 | 配置建议 |
|---|---|---|
| 数据安全性优先 | AOF + everysec | appendonly yes + appendfsync everysec |
| 性能优先 | RDB | save 3600 1（降低触发频率） |
| 平衡安全和性能 | 混合持久化 | aof-use-rdb-preamble yes + appendfsync everysec |
| 主从架构 | 主库：混合持久化，从库：RDB | 主库保证数据安全，从库加速复制 |
| 大规模数据 | 混合持久化 | 结合RDB快速恢复和AOF高安全性 |
7. 总结
Redis持久化机制是保证数据可靠性的核心，不同的持久化方式有各自的优缺点：
- RDB：适合大规模数据恢复，备份友好，但数据安全性较低。
- AOF：数据安全性高，但文件大、恢复慢。
- 混合持久化：结合两者优势，是Redis 4.0+的推荐方案。
选择持久化策略时，需根据业务对数据安全性 、性能 、恢复速度的要求综合考虑，合理配置参数，确保Redis既高效又可靠。