Redis 持久化机制

1. 为什么 Redis 需要持久化

• Redis 是 内存数据库，默认所有数据都存在 RAM 里，速度非常快，但：
  • 不持久化 → 断电、崩溃、重启数据全丢。
  • 持久化 → 把内存数据保存到磁盘，下次启动时能恢复。
• Redis 提供了两大持久化机制：
  • RDB（快照）
  • AOF（Append Only File）
  • 4.0+ 还支持 混合持久化（RDB + AOF）。

2. RDB（Redis DataBase）快照

2.1原理

• 在指定时间间隔内，把内存数据完整保存成一个 .rdb 二进制文件。
• 文件默认在 dump.rdb，启动时直接加载。

2.2 触发方式

2.2.1 自动触发（配置 save）

save 900 1   # 900秒(15分钟)内至少1次写入
save 300 10  # 300秒(5分钟)内至少10次写入
save 60 10000 # 60秒内至少1万次写入

2.2.2 手动触发

• SAVE（阻塞）
• BGSAVE（后台 fork 子进程写文件，不阻塞主线程）

2.3优缺点

2.3.1 优点

• 恢复速度快（文件紧凑）。
• 单个文件，易于备份、迁移。
• 对读写性能影响小（BGSAVE 时）。

2.3.2 缺点

• 可能丢数据（两次快照之间的修改不会保存）。
• 快照过程需要 fork 子进程，内存会瞬间翻倍。

2.3.3 适用场景

• 数据更新不频繁，对数据丢失不敏感（如缓存、排行榜）。
• 需要周期性全量备份。

3. AOF（Append Only File）日志

3.1 原理

• 把每一次写操作命令追加到 AOF 文件（appendonly.aof）。
• Redis 启动时重放命令来恢复数据。

3.2 配置示例

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec  # 每秒刷一次磁盘（推荐）

3.3 appendfsync 模式

3.4 优缺点

3.4.1 优点

• 数据安全性高（特别是 always 模式）。
• 日志文件可读（可手动修复）。

3.4.2 缺点

• 文件体积大（需要 BGREWRITEAOF 压缩）。
• 恢复速度比 RDB 慢。

3.5 适用场景

对数据安全要求高的业务（如金融、订单、聊天记录）。

4. 混合持久化（RDB + AOF）

4.1 原理

• 在 AOF rewrite 时，先写入一份 RDB 快照（内存数据的二进制），再追加 AOF 增量命令。
• 启动恢复时先加载 RDB 部分，再回放少量 AOF，启动速度快。

4.2 优缺点

4.2.1 优点

• 启动快（因为有 RDB 基础）。
• 数据安全性高（AOF 保存最近变更）。

4.2.2 缺点

• 文件格式更复杂，不兼容旧版本。

5. 持久化方案对比