#RDB vs AOF 对比与选型

面试官问："Redis 持久化用 RDB 还是 AOF？"

小张说："都用。"

面试官追问："为什么两个都要？各自的优缺点是什么？"

小张说："RDB 快，AOF 安全？"

面试官继续追问："那 RDB 和 AOF 可以同时用吗？恢复的时候用哪个？"

小陈答不上来。

RDB 和 AOF 是 Redis 持久化的两大支柱。这道题能说清楚两者对比和选型原则的候选人，对 Redis 的持久化机制有系统理解。

#一、RDB vs AOF 全维度对比 🔴

#1.1 核心对比表

#1.2 数据安全性对比

-- RDB：
-- 如果每 5 分钟 BGSAVE 一次
-- Redis 崩溃，最多丢失 5 分钟数据

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

-- AOF（always）：
-- 几乎不丢数据

#1.3 ❌ 错误示范

候选人原话："AOF 永远比 RDB 安全。"

问题诊断：在某些场景下，AOF 可能比 RDB 更不安全。比如 everysec 模式下，如果 Redis 在两次 fsync 之间崩溃，仍然会丢失 1 秒数据。

候选人原话 2："RDB 和 AOF 恢复时用同一个。"

问题诊断：Redis 启动时，如果同时存在 RDB 和 AOF，优先用 AOF 恢复（因为 AOF 数据更完整）。

【面试官心理】 这道题我能从"恢复优先级"追问。如果候选人能说出"AOF 恢复优先于 RDB"，说明他理解了 Redis 启动时的数据加载顺序。

#二、同时启用 RDB 和 AOF 🔴

#2.1 配置方式

# redis.conf
# RDB 配置
save 900 1
save 300 10
save 60 10000

# AOF 配置
appendonly yes
appendfsync everysec

#2.2 恢复优先级

Redis 启动加载数据时：
1. 检查 AOF 是否存在
2. 如果 AOF 存在，用 AOF 恢复（忽略 RDB）
3. 如果只有 RDB，用 RDB 恢复

为什么优先 AOF？
AOF 记录了更多数据（最后一次 RDB 之后的所有操作）

#2.3 子进程开销

-- 同时开启 RDB 和 AOF 时：
-- - RDB BGSAVE：fork 子进程（短暂阻塞）
-- - AOF 重写（BGREWRITEAOF）：fork 子进程

-- 如果两个同时触发，可能有问题
-- 解决：Redis 默认禁止在 AOF 重写时触发 RDB BGSAVE

#三、生产选型建议 🟡

#3.1 选型决策树

-- Q1：对数据丢失容忍度如何？
--   容忍 → RDB（简单、快速）
--   不容忍 → 继续

-- Q2：数据量有多大？
--   < 10GB → RDB + AOF 混合
--   > 10GB → AOF everysec

-- Q3：恢复速度要求如何？
--   需要快速恢复 → RDB（主要）+ AOF（辅助）
--   可以慢恢复 → AOF

#3.2 最佳实践

# 生产环境推荐配置
# redis.conf

# RDB：每天定时备份
save 900 1
save 300 10
# 关闭自动 RDB，使用 crontab 定时 BGSAVE

# AOF：实时持久化
appendonly yes
appendfsync everysec    # 推荐
# appendfsync always    # 数据要求极高时用

# AOF 重写优化
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 混合持久化
aof-use-rdb-preamble yes  # Redis 4.0+

#3.3 各场景推荐

#四、数据迁移与备份 🟢

#4.1 RDB 备份

# 定时任务备份 RDB
0 3 * * * redis-cli BGSAVE && sleep 5 && cp /var/redis/dump.rdb /backup/

#4.2 AOF 备份

# AOF 文件可以实时备份
# 主从复制时，从库会自动同步 AOF

#4.3 灾难恢复

# 场景：Redis 数据全部丢失
# 恢复步骤：
# 1. 找到最新的 RDB 备份
# 2. 找到 RDB 之后的所有 AOF 文件
# 3. 按顺序恢复
# 4. 如果有 AOF rewrite 文件，用最新的 rewrite 文件

【面试官心理】 持久化选型是 Redis 生产环境中的核心问题。能根据业务场景说出具体配置的候选人，说明他有生产经验。