【Redis】RDB 与 AOF

🗄️深入理解 Redis 持久化机制：RDB 与 AOF 的原理、优缺点与适用场景

Redis 是一款广泛应用的高性能键值对数据库。作为一个内存数据库，如果服务宕机，内存中的数据就会全部丢失。因此，为了保证数据的可靠性，Redis 提供了两种持久化机制：

• RDB（Redis DataBase）
• AOF（Append Only File）

本篇文章将带你从原理到实战，彻底搞懂这两种持久化方式的区别与使用建议。

📦 一、什么是持久化？

Redis 持久化是指将内存中的数据保存到磁盘中，以便在 Redis 重启后可以恢复数据。

🧊 二、RDB（快照机制）

🔧 原理：

RDB（Redis DataBase）是将 Redis 某个时刻的内存数据快照保存成一个 .rdb 文件（默认名为 dump.rdb）。

📌 触发方式：

• 自动触发：通过配置 save 规则（如：save 900 1 表示 900 秒内有至少 1 次写操作）。

• 手动触发：

  • SAVE 命令（阻塞式）
  • BGSAVE 命令（后台 fork 子进程执行，不阻塞主线程）

✅ 优点：

• 效率高：压缩保存，适合冷备份、灾难恢复。
• 恢复速度快：启动时直接读取 .rdb 文件加载内存。
• 对性能影响小：采用子进程执行，不阻塞主线程。

❌ 缺点：

• 数据丢失风险高：只能保存快照，中间的新数据容易丢失；
• fork 子进程耗资源：频繁触发可能对 CPU 和内存造成压力；
• 不适合实时性要求高的场景。

📝 三、AOF（日志机制）

🔧 原理：

AOF（Append Only File）记录 Redis 所执行的每一个写操作命令（如 SET、INCR 等），并以日志的形式顺序写入文件（appendonly.aof）。

Redis 重启时，通过重放日志命令重建数据。

📌 写入策略（由配置决定）：

appendfsync always      # 每次写操作都立即写入磁盘（安全但慢）
appendfsync everysec    # 每秒写入一次（默认，性能与安全的折中）
appendfsync no          # 依赖操作系统缓冲区（最快但不可靠）

✅ 优点：

• 数据更安全：每个写操作都被记录，可最大程度避免数据丢失；
• 可读性好：AOF 文件是纯文本，便于排查问题；
• 支持 AOF 重写机制：定期将旧命令压缩合并，减少文件体积。

❌ 缺点：

• 文件较大：比 RDB 文件大很多；
• 恢复速度慢：启动时需要重放所有写命令；
• 写入频繁时性能略低于 RDB。

🆚 四、RDB vs AOF 对比总结

🛠️ 五、实际应用建议

✅ 单选使用：

• 对数据恢复速度要求高：优先使用 RDB
• 对数据安全性要求高：优先使用 AOF

✅ 组合使用（推荐）：

Redis 支持同时开启 RDB 和 AOF，这样可以兼顾数据安全性与恢复速度：

appendonly yes
appendfsync everysec
save 900 1

启动恢复时优先加载 AOF，如果损坏则回退到 RDB。

📚 六、常用配置（redis.conf）

# RDB 配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

# AOF 配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

🎯 七、总结一句话

RDB 更适合全量快照和快速恢复，AOF 更适合高可用和数据完整性。生产环境中建议两者结合使用，以最大限度保证数据的安全与效率。

🔁 Redis 数据恢复机制详解：RDB、AOF 与 4.0 混合持久化

Redis 是一款典型的内存数据库，其高性能依赖于数据完全保存在内存中，但这也带来了风险 —— 一旦 Redis 异常宕机，内存中的数据将全部丢失。

为了解决这个问题，Redis 提供了两种持久化机制（RDB 与 AOF），并在 Redis 4.0 引入了更高效的数据持久化方式：混合持久化。

本文将深入讲解 Redis 的数据恢复方式，以及 Redis 4.0 的混合持久化机制，帮助你构建更加稳健的数据系统。

🧱 一、Redis 如何实现数据恢复？

Redis 重启后并不是“空白启动”，而是会尝试从磁盘中读取持久化文件，恢复之前的内存状态。

Redis 支持以下恢复来源：

启动顺序：

1. 若开启 AOF 且文件存在，优先从 AOF 恢复；
2. 若未开启 AOF 或 AOF 文件损坏，从 RDB 恢复；
3. 若都不可用，启动为空实例。

Redis 启动时加载数据的流程：

1. AOF持久化开启且存在AOF文件时，优先加载AOF文件。
2. AOF关闭或者AOF文件不存在时，加载RDB文件。
3. 加载AOF/RDB文件成功后，Redis启动成功。
4. AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

💾 二、RDB 与 AOF 的恢复机制

1️⃣ 从 RDB 文件恢复

• Redis 会直接加载 dump.rdb 文件；
• 这是 Redis 某一时刻内存状态的快照；
• 恢复速度快，但可能会丢失最后一次快照之后的数据。

# 触发 RDB 生成（手动）
127.0.0.1:6379> BGSAVE

2️⃣ 从 AOF 文件恢复

• Redis 会从头开始重放 AOF 中的所有写命令；
• 恢复结果更完整，但速度较慢；
• 如果 AOF 文件过大，恢复时间会变长。

# 开启 AOF 的配置
appendonly yes
appendfsync everysec

Redis 会根据 AOF 文件记录的命令，逐条执行并重建内存数据。

🧬 三、Redis 4.0 引入的“混合持久化”机制

🧪 混合持久化是什么？

Redis 4.0 开始，支持将 RDB 数据 + 后续 AOF 命令 一起写入到 AOF 文件中，形成一种新格式，称为 混合持久化。

📦 混合持久化格式：

[ RDB 快照内容 ][ AOF 增量命令 ]

• 启动时，Redis 首先从文件中加载 RDB 快照数据；
• 然后再执行 RDB 之后的写命令（追加部分）；
• 兼具 RDB 快速恢复 和 AOF 高完整性 的优势。

✅ 开启方式：

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

🔍 优点：

🔁 四、如何手动触发恢复

场景：Redis 宕机后重启恢复

1. Redis 宕机或 kill -9；
2. 重启 Redis 服务；
3. Redis 自动寻找 AOF/RDB 文件，进行恢复；
4. 恢复后自动接收客户端请求，正常服务。

常见命令：

# 查看是否正在恢复
ps aux | grep redis

# 查看持久化文件是否存在
ls dump.rdb
ls appendonly.aof

📌 五、使用建议

推荐配置（redis.conf）：

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 900 1
save 300 10

🧠 六、总结

Redis 4.0 之后，混合持久化是生产环境中最推荐的持久化方式，它结合了两种机制的优势，确保高可用与高性能并存。