Redis 持久化机制详解

最近在准备面试，正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解，以及高频业务场景的应对策略系统梳理一遍，既能加深记忆，也能让知识体系更扎实，供大家参考，欢迎讨论。

持久化是指将内存中的数据保存到本地磁盘中，以防止服务器宕机时造成内存数据丢失。Redis 提供了两种主要的持久化机制：RDB 和 AOF。从 Redis 4.0 版本开始，还引入了混合持久化机制，结合了 RDB 和 AOF 的优势。

RDB 持久化（Redis DataBase）

RDB 是 Redis 默认的持久化方式，它通过生成内存数据的快照（snapshot）并将其保存到硬盘上的 dump.rdb 文件中来实现持久化。快照的生成周期可以通过配置文件中的 save 参数进行设置。

RDB 的优点：

1. 文件紧凑：只有一个 dump.rdb 文件，便于备份和传输。
2. 容灾性好：可以将文件保存到安全的磁盘或远程位置。
3. 性能最大化：通过 fork 子进程执行持久化操作，主进程继续处理命令，仅存在毫秒级的请求延迟。
4. 恢复效率高：在数据集较大时，RDB 的恢复速度比 AOF 更快。

RDB 的缺点：

• 数据安全性较低：由于是周期性持久化，如果在两次快照之间 Redis 发生故障，可能会丢失部分数据。

---

AOF 持久化（Append Only File）

AOF 持久化通过记录 Redis 执行的每一条写命令到单独的日志文件中（默认是 appendonly.aof），在重启时通过重新执行这些命令来恢复数据。

AOF 的优点：

1. 数据完整性高：可以通过配置 appendfsync 选项（如 always）确保每次写操作都立即记录到 AOF 文件中。
2. 容灾机制完善：即使 AOF 文件损坏，也可以通过 redis-check-aof 修复。
3. AOF重写机制：AOF重写会在AOF文件体积过大（通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数控制增长率）时自动触发，或通过执行BGREWRITEAOF命令手动触发，其核心目的是通过遍历内存数据生成最精简的命令序列来替换臃肿的旧文件，从而解决持续追加命令导致的文件膨胀和恢复效率低下问题。

AOF 的缺点：

1. 文件体积大：AOF 文件通常比 RDB 文件大。
2. 恢复速度慢：需要逐条执行日志中的命令，恢复速度较慢。
3. 启动效率低：在数据集较大时，AOF 的启动效率低于 RDB。

混合持久化（Redis 4.0+）

背景：

• RDB 恢复可能丢失大量数据。

• AOF 日志重放性能较差，大实例启动耗时久。

开启条件：

1. 需要先开启 AOF（配置 appendonly yes）。
2. 通过设置 aof-use-rdb-preamble yes 开启混合持久化。

优势：

• Redis 重启时，先加载 RDB 内容（快速恢复大部分数据），再重放增量 AOF 日志，大幅提升重启效率。

文件结构：

混合 AOF 文件由两部分组成：

1. RDB 格式的内容（存储某一时刻的数据快照）。
2. AOF 格式的增量命令（记录快照之后的写操作）。

总结

• RDB 适合对恢复速度要求高、能容忍少量数据丢失的场景。

• AOF 适合对数据可靠性要求极高的场景。之前互联网工作经常用到的。

• 混合持久化结合了 RDB 和 AOF 的优点，是 Redis 4.0 及以上版本的推荐方案。当下工作使用的，技术一直在发展这个优势更大。