Redis 的持久化机制有哪些？

Redis 持久化机制详解

【核心定义】

Redis 持久化是指将内存中的数据以特定格式保存到磁盘，确保服务重启后数据不丢失的机制，主要包含 RDB 和 AOF 两种核心策略。

【关键要点】

1. RDB（Redis Database）快照持久化

   • 本质：在指定时间间隔生成数据集的二进制快照文件（dump.rdb）
   • 触发方式：手动 SAVE/BGSAVE 命令、配置文件中 save 规则、主从复制全量同步
   • 文件特点：紧凑压缩的二进制格式，适合备份和灾难恢复

2. AOF（Append Only File）日志持久化

   • 本质：记录每个写操作命令到日志文件，重启时重新执行命令恢复数据
   • 写入策略：
     • always：每个写命令都同步到磁盘（最安全，性能最低）
     • everysec：每秒同步一次（平衡方案，默认推荐）
     • no：由操作系统决定同步时机（性能最高，风险最大）
   • 重写机制：AOF 文件过大时自动重写，生成最简命令序列

3. 混合持久化（Redis 4.0+）

   • 本质：RDB 快照 + 增量 AOF 日志的组合方案
   • 工作流程：先写入 RDB 格式的全量数据，再追加期间的 AOF 增量命令
   • 优势：结合了 RDB 快速加载和 AOF 数据安全的双重优点

【深度推导/细节】

RDB 的生成机制与权衡

核心矛盾：数据一致性 vs 性能开销

BGSAVE 执行流程：

Step 1: 主进程 fork() 创建子进程（Copy-On-Write 机制）
Step 2: 子进程遍历内存数据，序列化为 RDB 格式
Step 3: 子进程完成写入后，用新文件原子替换旧文件
Step 4: 子进程退出，通知主进程

关键数字解析：

• save 900 1：900 秒内至少 1 个 key 被修改则触发 BGSAVE
• 设计合理性：平衡数据安全性和磁盘 I/O 压力，避免频繁快照

AOF 的重写优化逻辑

核心问题：AOF 文件膨胀导致恢复时间过长

AOF 重写流程：

Step 1: 主进程 fork() 创建重写子进程
Step 2: 子进程读取当前数据库快照，转换为最小命令集
Step 3: 主进程继续处理命令，同时将新命令写入 AOF 缓冲区和重写缓冲区
Step 4: 子进程完成重写后，主进程将重写缓冲区命令追加到新 AOF
Step 5: 原子替换旧 AOF 文件

重写触发条件：

• 自动触发：AOF 文件大小超过上次重写后大小的 100%（可配置）
• 手动触发：执行 BGREWRITEAOF 命令

【关联/对比】

RDB vs AOF 核心差异

Redis 持久化 vs 传统数据库

• Redis：内存优先，持久化为补充方案
• MySQL：磁盘优先，WAL（Write-Ahead Logging）为核心机制
• 本质区别：Redis 持久化目标是保证重启后数据可恢复，而非 ACID 事务保证

【版本差异】

• Redis 2.4+：引入 AOF 重写
• Redis 2.8+：AOF 支持增量 fsync
• Redis 4.0+：引入混合持久化（RDB-AOF）
• Redis 7.0+：多部分 AOF 文件，支持历史 AOF 文件管理

【生产实践建议】

1. 推荐配置：RDB（每日备份）+ AOF everysec（实时保护）
2. 监控要点：
   • fork() 耗时（RDB/AOF 重写时）
   • AOF 重写缓冲区大小
   • 持久化延迟时间
3. 灾难恢复：定期将 RDB 文件备份到异地

『面试官追问』

1. RDB 生成期间发生写操作会怎样？

   • 基于 Copy-On-Write 机制，子进程看到的是 fork 时刻的数据快照
   • 主进程的写操作会复制被修改的内存页，不影响子进程的序列化

2. AOF 重写期间服务崩溃怎么办？

   • Redis 设计了双缓冲机制：旧 AOF 文件保留直到新文件完全生成
   • 重启时会检测到不完整的重写，自动回滚到上次完整的 AOF

3. 如何选择持久化策略？

   • 数据可丢失场景：仅用 RDB
   • 高安全性要求：AOF always + RDB 定期备份
   • 平衡方案：RDB（定时备份）+ AOF everysec（默认推荐）

4. 混合持久化如何工作？

   • 生成的文件前半部分是 RDB 格式，后半部分是 AOF 格式
   • 加载时先快速加载 RDB 部分，再执行 AOF 部分的增量命令

5. 持久化对性能的影响如何量化？

   • RDB：fork() 时间与内存大小成正比（约每 GB 20ms）
   • AOF always：每个命令增加约 10ms 的 fsync 延迟
   • AOF everysec：性能损失约 2-5%

6. 主从架构下的持久化策略？

   • 建议在从节点开启持久化，减轻主节点压力
   • 利用从节点的 RDB 文件进行数据备份