我要评论一、核心概念回顾
rdb vs aof 对比
| 特性 | rdb (快照) | aof (日志) |
|---|---|---|
| 原理 | 定时全量快照 | 记录每条写命令 |
| 文件格式 | 二进制 (.rdb) | 文本日志 (.aof) |
| 文件大小 | 小 | 大 |
| 恢复速度 | 快 (直接加载) | 慢 (重放命令) |
| 数据完整性 | 可能丢失快照间数据 | 可做到秒级甚至实时 |
| 性能影响 | 快照时 fork 子进程 | 持续写磁盘，有开销 |
二、同时开启 rdb+aof 的工作机制
1. 写入流程（双写机制）
┌─────────────────────────────────────────────────────────────────┐
│ redis 写操作流程 │
└─────────────────────────────────────────────────────────────────┘
写命令 (set/del/hset...)
↓
┌───────────────┐
│ 内存数据 │ ← 立即执行
└───────┬───────┘
│
┌───────┴───────┐
↓ ↓
┌──────────────┐ ┌──────────────┐
│ rdb 快照 │ │ aof 日志 │
│ (定时触发) │ │ (实时追加) │
│ .rdb 文件 │ │ .aof 文件 │
└──────────────┘ └──────────────┘关键点：
rdb：按配置的时间间隔触发（如 900 秒有 1 次修改）
aof：每条写命令都记录（根据 fsync 策略决定何时落盘）
2. 混合持久化（redis 4.0+ 核心特性）
这是最重要的配置！redis 4.0 引入了 aof-rdb 混合持久化：
┌─────────────────────────────────────────────────────────────────┐ │ 混合持久化文件格式 │ └─────────────────────────────────────────────────────────────────┘ appendonly.aof 文件结构： ┌─────────────────────────────────────────────────────────────────┐ │ 头部：rdb 格式快照数据 (全量数据) │ │ ───────────────────────────────────────────────────────────── │ │ 尾部：aof 格式增量命令 (rdb 之后的写操作) │ │ ───────────────────────────────────────────────────────────── │ │ 结尾：eof 标记 │ └─────────────────────────────────────────────────────────────────┘ 优势： ✓ 恢复时先加载 rdb 快照（快） ✓ 再重放少量 aof 增量命令（数据完整） ✓ 兼顾速度和完整性
配置项：
# redis.conf aof-use-rdb-preamble yes # 开启混合持久化（redis 4.0+ 默认开启）
3. aof 重写时的混合机制
aof 文件会越来越大，需要定期重写（rewrite）：
┌─────────────────────────────────────────────────────────────────┐
│ aof 重写流程 │
└─────────────────────────────────────────────────────────────────┘
重写前 appendonly.aof：
┌─────────────────────────────────────────────────────────────────┐
│ rdb 快照 │ set k1 v1 │ set k1 v2 │ del k1 │ set k2 v2 │ ... │
│ (旧数据) │ (重复命令很多，文件膨胀) │
└─────────────────────────────────────────────────────────────────┘
↓ bgrewriteaof 触发
重写后 appendonly.aof：
┌─────────────────────────────────────────────────────────────────┐
│ rdb 快照 (当前最新数据) │ set k2 v2 │ (增量命令) │
│ (紧凑二进制) │ (少量新命令) │
└─────────────────────────────────────────────────────────────────┘
结果：
✓ 文件体积大幅减小
✓ 恢复速度更快
✓ 数据不丢失三、重启恢复优先级
恢复顺序规则
┌─────────────────────────────────────────────────────────────────┐
│ redis 重启恢复流程 │
└─────────────────────────────────────────────────────────────────┘
redis 启动
↓
┌───────────────────────┐
│ 检查持久化文件是否存在 │
└───────────┬───────────┘
│
┌───────────────┼───────────────┐
↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ aof 存在 │ │ 仅 rdb │ │ 都无 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
↓ ↓ ↓
优先用 aof 用 rdb 恢复 空数据库
(数据更完整) (快照数据) (无历史数据)
│ │ │
└──────────────┴──────────────┘
↓
┌─────────────────┐
│ 恢复完成 │
│ 对外提供服务 │
└─────────────────┘核心原则：
- aof 优先级 > rdb 优先级
- 原因：aof 数据通常比 rdb 更完整（丢失数据更少）
四、生产环境配置推荐
完整配置示例
# ==================== rdb 配置 ==================== dbfilename dump.rdb # rdb 文件名 dir /var/lib/redis # 数据目录 # 快照触发条件（满足任一即触发） save 900 1 # 900 秒内至少 1 个 key 变化 save 300 10 # 300 秒内至少 10 个 key 变化 save 60 10000 # 60 秒内至少 10000 个 key 变化 stop-writes-on-bgsave-error yes # rdb 失败时停止写入 rdbcompression yes # 压缩 rdb 文件 rdbchecksum yes # 校验和 # ==================== aof 配置 ==================== appendonly yes # 开启 aof appendfilename "appendonly.aof" # aof 文件名 # aof 落盘策略（三选一） appendfsync everysec # 推荐：每秒同步（性能与安全平衡） # appendfsync always # 每次写都同步（最安全，性能差） # appendfsync no # 由系统决定（性能最好，可能丢数据） no-appendfsync-on-rewrite no # 重写时是否禁用 fsync auto-aof-rewrite-percentage 100 # aof 增长 100% 时触发重写 auto-aof-rewrite-min-size 64mb # aof 最小 64mb 才触发重写 # ==================== 混合持久化 ==================== aof-use-rdb-preamble yes # 开启混合持久化（关键！）
五、两种模式对比
模式一：传统双持久化（redis 4.0 之前）
┌─────────────────────────────────────────────────────────────────┐ │ 传统双持久化 │ └─────────────────────────────────────────────────────────────────┘ 文件结构： ┌─────────────────────┐ ┌─────────────────────────────────┐ │ dump.rdb │ │ appendonly.aof │ │ (独立 rdb 文件) │ │ (纯 aof 日志，无 rdb 前缀) │ │ 全量快照 │ │ 所有写命令 │ └─────────────────────┘ └─────────────────────────────────┘ 恢复时： 1. 优先加载 aof 文件 2. 逐条重放所有命令 3. rdb 文件仅作为备份 缺点： ✗ aof 文件大 ✗ 恢复慢 ✗ 两份文件独立管理
模式二：混合持久化（redis 4.0+ 推荐）
┌─────────────────────────────────────────────────────────────────┐ │ 混合持久化 │ └─────────────────────────────────────────────────────────────────┘ 文件结构： ┌─────────────────────────────────────────────────────────────────┐ │ appendonly.aof (唯一持久化文件) │ │ ┌─────────────────┬───────────────────────────────────────┐ │ │ │ rdb 快照部分 │ aof 增量命令部分 │ │ │ │ (二进制格式) │ (文本命令格式) │ │ │ │ 基础数据 │ rdb 之后的写操作 │ │ │ └─────────────────┴───────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ 恢复时： 1. 加载 rdb 快照部分（快速） 2. 重放 aof 增量命令（少量） 3. dump.rdb 文件不再使用 优点： ✓ 恢复速度快 ✓ 数据完整性高 ✓ 文件管理简单
六、实际场景演示
场景：redis 重启恢复
时间线： t0: redis 启动，开启 rdb+aof 混合持久化 t1: 写入 100 万条数据 t2: 触发 rdb 快照 → dump.rdb 生成 t3: aof 持续记录写命令 t4: aof 重写 → appendonly.aof 包含 rdb 快照 + 增量命令 t5: redis 宕机 t6: redis 重启 恢复过程： ┌─────────────────────────────────────────────────────────────────┐ │ 步骤 1: 检测文件 │ │ - 发现 appendonly.aof 存在 │ │ - 发现 dump.rdb 存在（但不用） │ ├─────────────────────────────────────────────────────────────────┤ │ 步骤 2: 加载 aof 文件 │ │ - 读取 rdb 前缀部分 → 恢复 100 万条基础数据 (约 2 秒) │ │ - 重放 aof 增量命令 → 恢复 t4-t5 期间的写操作 (约 0.5 秒) │ ├─────────────────────────────────────────────────────────────────┤ │ 步骤 3: 恢复完成 │ │ - 总耗时约 2.5 秒 │ │ - 数据丢失：仅 t5 时刻未 fsync 的少量数据 │ └─────────────────────────────────────────────────────────────────┘ 对比纯 rdb 恢复： - 恢复时间：约 2 秒 - 数据丢失：t2-t5 期间所有写操作（可能几小时数据） 对比纯 aof 恢复： - 恢复时间：约 30 秒+（重放所有命令） - 数据丢失：仅 t5 时刻未 fsync 的少量数据
七、最佳实践总结
| 场景 | 推荐配置 | 理由 |
|---|---|---|
| 生产环境 | rdb+aof 混合持久化 | 性能与安全最佳平衡 |
| 高写入场景 | appendfsync everysec | 每秒同步，性能影响小 |
| 金融级数据 | appendfsync always | 不丢数据，接受性能损失 |
| 纯缓存场景 | 可关闭持久化 | 追求极致性能 |
| redis 版本 | 4.0+ | 支持混合持久化 |
监控建议
# 检查持久化状态 redis-cli info persistence # 关键指标： # - rdb_last_bgsave_status: rdb 最后保存状态 # - aof_enabled: aof 是否开启 # - aof_last_rewrite_time_sec: aof 最后重写耗时 # - aof_current_size: aof 当前文件大小
八、总结
| 问题 | 答案 |
|---|---|
| rdb 和 aof 能同时开吗？ | 可以，且生产环境推荐同时开启 |
| 恢复时优先用哪个？ | aof 优先级更高（数据更完整） |
| 混合持久化是什么？ | aof 文件头部存 rdb 快照，尾部存增量命令 |
| 需要配置什么？ | aof-use-rdb-preamble yes（4.0+ 默认开启） |
| 最佳实践？ | redis 4.0+ 使用混合持久化 + appendfsync everysec |
| redis 4.0+ 有几个持久化文件？ | 两个：dump.rdb + appendonly.aof |
| redis 4.0+ appendonly.aof 内容是什么？ | rdb 快照前缀 + aof 增量命令 |
| redis 4.0+ dump.rdb 还会生成吗？ | 会，只要 save 配置生效 |
| redis 4.0+ dump.rdb 有什么用？ | 备份、降级兼容、手动恢复 |
| redis 4.0+ 能删除 dump.rdb 吗？ | 可以，但不推荐（失去备份） |
| redis 4.0+ 如何只保留一个文件？ | 配置 save "" 禁用 rdb（不推荐） |
| redis 版本 | 持久化模式 | dump.rdb | appendonly.aof | 恢复时使用哪个 |
|---|---|---|---|---|
| 4.0 之前 | 仅 rdb | ✓ 存在 | ✗ 不存在 | rdb |
| 4.0 之前 | 仅 aof | ✗ 不存在 | ✓ 存在 | aof |
| 4.0 之前 | rdb+aof | ✓ 存在 | ✓ 存在 | aof（优先） |
| 4.0+ | 混合持久化 | ✓ 存在 | ✓ 存在 | aof（含 rdb 前缀） |
核心要点：
- redis 4.0+ 的混合持久化是生产环境的标准配置，它巧妙地将 rdb 的快速恢复和 aof 的数据完整性结合起来，通过单一的 aof 文件同时存储快照和增量日志，实现了性能和安全的最优平衡。
- redis 4.0+ 混合持久化后，dump.rdb 和 appendonly.aof 两个文件都会存在。dump.rdb 虽然恢复时不用，但仍然作为独立备份存在，提供降级兼容和冷备能力。appendonly.aof 才是真正用于恢复的主文件（包含 rdb 快照 + 增量命令）。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论