持久化机制

Redis 是内存数据库，持久化机制确保数据不会因进程退出或服务器宕机而丢失。

持久化方式概览 ⭐⭐⭐⭐⭐

Redis 提供了 3 种持久化方式：

方式	说明	优点	缺点
RDB	快照（Snapshot）	文件小、恢复快、性能影响小	可能丢失最后一次快照之后的数据
AOF	追加日志（Append Only File）	数据安全性高、可读性好	文件大、恢复慢、性能影响大
混合持久化	RDB + AOF 混合（4.0+）	结合两者优点	Redis 4.0+ 才支持

---

RDB 持久化 ⭐⭐⭐⭐⭐

工作原理

RDB 持久化是通过创建快照的方式，将某个时间点的所有数据保存到磁盘。

触发方式：

1. 手动触发：SAVE 或 BGSAVE 命令

2. 自动触发：配置文件中的 save 规则

SAVE vs BGSAVE

命令	阻塞	实现方式	使用场景
SAVE	是	主进程直接执行，阻塞所有请求	几乎不用（会阻塞服务）
BGSAVE	否	fork 子进程执行，主进程继续处理请求	生产环境使用

BGSAVE 流程：

1. Redis 主进程 fork 一个子进程
2. 子进程将数据写入临时 RDB 文件
3. 写入完成后，原子性地替换旧的 RDB 文件
4. 子进程退出

fork 时的 Copy-On-Write（COW）机制：

fork 时不会复制整个内存，而是复制页表（Page Table）
只有当父进程或子进程修改数据时，才会复制对应的内存页

优点：fork 速度快，内存占用少
缺点：如果在 RDB 期间有大量写操作，可能占用 2 倍内存

配置详解

redis.conf 配置：

# 自动触发规则（满足任一条件就触发）
save 900 1      # 900 秒内至少 1 次修改
save 300 10     # 300 秒内至少 10 次修改
save 60 10000   # 60 秒内至少 10000 次修改

# 禁用自动保存（只能手动触发）
save ""

# RDB 文件名
dbfilename dump.rdb

# RDB 文件存储路径
dir /var/lib/redis

# 后台保存失败时是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩 RDB 文件（使用 LZF 压缩）
rdbcompression yes

# 是否对 RDB 文件进行校验（CRC64）
rdbchecksum yes

RDB 文件格式

┌─────────────────────────────────────────────────────────────┐
│  REDIS 魔数  │  版本号  │  数据库选择  │  键值对  │  EOF  │  校验和  │
│   (5 bytes)  │ (4 bytes)│              │          │ (1 byte)│ (8 bytes)│
└─────────────────────────────────────────────────────────────┘

手动触发示例

# 同步保存（阻塞，不推荐）
SAVE

# 异步保存（推荐）
BGSAVE

# 查看最后一次保存时间
LASTSAVE

# 查看 RDB 保存状态
INFO persistence

RDB 的优缺点

优点：

1. 文件紧凑：全量快照，文件小，适合备份和灾难恢复

2. 恢复速度快：直接加载 RDB 文件，速度快于 AOF

3. 性能影响小：使用子进程，对主进程性能影响小

4. 适合大规模数据恢复：可以快速恢复 GB 级数据

缺点：

1. 数据丢失风险：两次快照之间的数据可能丢失

2. fork 耗时：数据量大时，fork 可能耗时较长（几百 ms）

3. 不适合实时性要求高的场景：RDB 间隔时间长，可能丢失较多数据

使用场景

• 数据备份：定期备份 RDB 文件到其他服务器

• 灾难恢复：RDB 文件可快速恢复数据

• 从节点持久化：主从架构中，从节点使用 RDB

• 可接受分钟级数据丢失的场景

---

AOF 持久化 ⭐⭐⭐⭐⭐

工作原理

AOF（Append Only File）通过记录写命令的方式持久化数据。

流程：

1. 客户端发送写命令（SET、HSET、LPUSH 等）
2. Redis 执行命令并将命令追加到 AOF 缓冲区
3. 根据 appendfsync 策略将缓冲区内容写入 AOF 文件
4. 定期重写 AOF 文件，压缩文件大小

开启 AOF

redis.conf 配置：

# 启用 AOF
appendonly yes

# AOF 文件名
appendfilename "appendonly.aof"

# AOF 文件存储路径（与 RDB 相同）
dir /var/lib/redis

同步策略：appendfsync ⭐⭐⭐⭐⭐

策略	说明	性能	安全性	数据丢失
always	每个写命令都同步到磁盘	差	高	几乎不丢失
everysec	每秒同步一次（默认）	好	较高	最多丢失 1 秒数据
no	由操作系统决定何时同步	最好	低	可能丢失多秒数据

推荐配置：

# 生产环境推荐
appendfsync everysec

# 平衡性能和安全性
# 最多丢失 1 秒数据，性能影响小

AOF 重写 ⭐⭐⭐⭐⭐

为什么需要重写？

AOF 文件会越来越大，因为它记录了所有写命令。

例如：
SET key value1
SET key value2
SET key value3
...
SET key value100

重写后：
SET key value100   # 只保留最终状态

重写方式：

1. 手动触发：

BGREWRITEAOF

2. 自动触发：

# 当前 AOF 文件大小超过上次重写后的 100%，且大于 64MB 时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

重写流程：

1. Redis fork 一个子进程
2. 子进程遍历内存中的数据，生成新的 AOF 文件
3. 期间主进程的写命令同时写入：
   - AOF 缓冲区（写入旧 AOF 文件）
   - AOF 重写缓冲区（子进程完成后追加到新 AOF 文件）
4. 子进程完成后，主进程将重写缓冲区内容追加到新 AOF 文件
5. 原子性地替换旧 AOF 文件

重写优化：

# 重写期间是否允许 AOF 追加（no 性能更好但可能阻塞）
aof-rewrite-incremental-fsync yes

# AOF 重写期间主进程是否执行 fsync（no 性能更好）
no-appendfsync-on-rewrite no

AOF 文件格式

AOF 文件是纯文本格式，使用 RESP 协议：

# SET name "Zhang"
*3           # 3 个参数
$3           # 第一个参数长度 3
SET
$4           # 第二个参数长度 4
name
$5           # 第三个参数长度 5
Zhang

查看 AOF 文件：

cat appendonly.aof

AOF 损坏修复

检查 AOF 文件：

redis-check-aof appendonly.aof

修复 AOF 文件：

redis-check-aof --fix appendonly.aof

AOF 的优缺点

优点：

1. 数据安全性高：everysec 模式最多丢失 1 秒数据

2. 可读性好：AOF 文件是文本格式，易于分析和修改

3. 支持增量备份：可以通过 AOF 文件回放历史操作

4. 自动重写：避免文件过大

缺点：

1. 文件大：比 RDB 文件大得多

2. 恢复慢：需要回放所有命令，速度慢于 RDB

3. 性能影响：写入频繁时，fsync 会影响性能

4. 可能出现 Bug：AOF 重写逻辑复杂，曾有 Bug 导致数据不一致

使用场景

• 数据安全性要求高：金融、电商等场景

• 可容忍一定性能损耗：写入不是特别频繁的场景

• 需要数据审计：可通过 AOF 文件回溯操作历史

---

混合持久化 ⭐⭐⭐⭐⭐

什么是混合持久化？

Redis 4.0 引入了混合持久化（RDB-AOF Hybrid Persistence），结合了 RDB 和 AOF 的优点。

原理：

AOF 重写时：
1. 子进程先将内存数据以 RDB 格式写入 AOF 文件（快照部分）
2. 然后将重写期间的写命令以 AOF 格式追加到文件末尾（增量部分）

AOF 文件结构：
┌─────────────────────────────────────────┐
│  RDB 格式的快照数据  │  AOF 格式的增量命令  │
└─────────────────────────────────────────┘

开启混合持久化

# Redis 4.0+ 默认开启
aof-use-rdb-preamble yes

混合持久化的优势

对比项	RDB	AOF	混合持久化
文件大小	小	大	适中（RDB 部分小）
恢复速度	快	慢	快（RDB 部分快速加载）
数据安全	差	好	好（AOF 增量保证）
兼容性	好	好	Redis 4.0+

最佳实践：

# 启用 AOF
appendonly yes

# 启用混合持久化
aof-use-rdb-preamble yes

# 每秒同步
appendfsync everysec

# 自动重写配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

---

RDB vs AOF vs 混合持久化 ⭐⭐⭐⭐⭐

对比表

特性	RDB	AOF	混合持久化
启动优先级	低	高	高（AOF 优先）
文件大小	小	大	适中
恢复速度	快	慢	快
数据完整性	可能丢失分钟级数据	最多丢失 1 秒	最多丢失 1 秒
CPU 占用	低	高（fsync）	适中
内存占用	fork 时可能 2 倍	稍高（缓冲区）	fork 时可能 2 倍
适用场景	备份、从节点	生产主节点	生产主节点（推荐）

启动时的加载优先级

Redis 启动时：
1. 如果 AOF 开启 → 加载 AOF 文件
2. 如果 AOF 关闭 → 加载 RDB 文件
3. 如果都没有 → 空实例启动

如何选择？

纯缓存场景（可接受数据丢失）：

# 只用 RDB
appendonly no
save 900 1
save 300 10
save 60 10000

数据重要场景（不能接受数据丢失）：

# 使用混合持久化（推荐）
appendonly yes
aof-use-rdb-preamble yes
appendfsync everysec

极致性能场景（内存充足）：

# 关闭持久化
appendonly no
save ""

---

持久化性能优化 ⭐⭐⭐⭐

1. 合理配置 fork 优化

# 内核参数优化（Linux）
# 允许内存过量分配
echo 1 > /proc/sys/vm/overcommit_memory

# 关闭透明大页（THP），避免 fork 时延迟
echo never > /sys/kernel/mm/transparent_hugepage/enabled

2. 避免磁盘 I/O 瓶颈

# 使用 SSD 磁盘存储 RDB/AOF 文件
dir /mnt/ssd/redis

# AOF 重写期间不执行 fsync（提升性能，略微降低安全性）
no-appendfsync-on-rewrite yes

3. 监控持久化状态

# 查看持久化信息
INFO persistence

# 关键指标：
# - rdb_last_save_time: 上次 RDB 保存时间
# - rdb_changes_since_last_save: 距上次保存的修改次数
# - aof_current_size: 当前 AOF 文件大小
# - aof_last_rewrite_time_sec: 上次 AOF 重写耗时

4. 避免大 key

# 大 key 会导致 RDB/AOF 操作变慢
# 建议单个 key 不超过 10MB

# 查找大 key
redis-cli --bigkeys

---

常见问题 ⭐⭐⭐⭐⭐

Q1: Redis 挂了数据会丢失吗？

答：取决于持久化配置：

• RDB：可能丢失最后一次快照之后的所有数据（分钟级）

• AOF（everysec）：最多丢失 1 秒数据

• AOF（always）：几乎不丢失数据（性能差）

• 无持久化：所有数据丢失

Q2: RDB 和 AOF 能同时开启吗？

答：可以，且推荐同时开启。

• Redis 重启时优先加载 AOF 文件（数据更完整）

• RDB 可用于备份和灾难恢复

Q3: fork 操作会阻塞主进程吗？

答：会，但时间很短（几毫秒到几百毫秒）。

• fork 只是复制页表，不复制数据

• 数据量越大，fork 耗时越长

• 可通过 INFO stats 查看 latest_fork_usec

Q4: AOF 文件损坏怎么办？

答：使用 redis-check-aof 工具修复：

redis-check-aof --fix appendonly.aof

Q5: 如何实现数据备份？

答：

1. 手动备份：定期执行 BGSAVE，复制 RDB 文件到其他服务器

2. 自动备份：定时任务（cron）备份 RDB 文件

3. 主从备份：搭建从节点，从节点自动同步数据

# 备份脚本示例
#!/bin/bash
redis-cli BGSAVE
sleep 10
cp /var/lib/redis/dump.rdb /backup/dump-$(date +%Y%m%d).rdb

Q6: Redis 4.0 之前没有混合持久化怎么办？

答：同时开启 RDB 和 AOF：

appendonly yes
appendfsync everysec
save 900 1

---

面试要点 ⭐⭐⭐⭐⭐

高频问题

Q1: Redis 的持久化方式有哪些？

• RDB（快照）、AOF（日志）、混合持久化（RDB + AOF）

Q2: RDB 和 AOF 的区别？

• RDB：全量快照，文件小，恢复快，可能丢失分钟级数据

• AOF：记录写命令，文件大，恢复慢，最多丢失 1 秒数据

Q3: AOF 的三种同步策略是什么？

• always：每次写入都同步，安全但慢

• everysec：每秒同步一次，推荐

• no：由 OS 决定，快但不安全

Q4: 什么是 AOF 重写？

• 遍历内存数据，生成最小命令集，压缩 AOF 文件大小

• 通过 fork 子进程异步执行，不阻塞主进程

Q5: 混合持久化的优势是什么？

• 文件大小适中（RDB 部分紧凑）

• 恢复速度快（RDB 部分快速加载）

• 数据安全性高（AOF 增量保证）

Q6: Redis 重启时如何加载数据？

• 优先加载 AOF（如果开启）

• 否则加载 RDB

• 都没有则空实例启动

Q7: fork 操作的原理是什么？

• 复制父进程的页表，不复制数据（Copy-On-Write）

• 只有修改时才复制对应内存页

• 数据量大时，fork 可能耗时较长

---

参考资料

1. 官方文档：Redis Persistence

2. 书籍推荐：

   • 《Redis 设计与实现》（黄健宏）

   • 《Redis 开发与运维》（付磊、张益军）

3. 源码：Redis Persistence 源码