📚 高级篇 05. Redis 持久化 - RDB 与 AOF 终极对比
一、 核心特性终极 PK (面试速记表)
在实际的架构选型中，没有绝对的好与坏，只有最适合业务场景的权衡（Trade-off）。
| 对比维度 | RDB (Redis Database / 快照) | AOF (Append Only File / 追加日志) |
|---|---|---|
| 持久化方式 | 定时对整个内存数据拍静态快照 | 实时记录执行的每一条写命令 |
| 数据完整性 (防丢能力) | 较低。 两次快照之间如果宕机，期间数据全丢。 | 极高。 配置 everysec 最多只丢 1 秒数据。 |
| 文件大小 | 小巧紧凑。 二进制压缩文件。 | 极大。 纯文本命令追加，即使有 Rewrite 机制，体积依然大于 RDB。 |
| 宕机恢复速度 | 极快。 直接将二进制数据按字节读入内存。 | 较慢。 需要单线程重新执行一遍日志里记录的海量命令。 |
| 系统资源开销 | 极高 (瞬间) 。 fork 子进程和 Copy-On-Write 会带来 CPU 和内存的突发峰值。 | 较低 (平稳) 。 主要是后台线程每秒极低成本的磁盘 I/O 刷盘。 |
| 核心定位 | 适合做冷备、灾难恢复 (异地容灾)。 | 适合做热备、保证核心业务数据不丢失。 |
二、 成年人不做选择题：企业级“混合持久化” (Redis 4.0+ 杀招)
如果你在面试中只答出了上面的表格，那只是及格分。面试官真正想听到的，是你在面对 RDB 和 AOF 各自缺陷时的破局思路。
- RDB 的痛： 容易丢数据。
- AOF 的痛： 文件太大，重启恢复太慢。
为了完美兼顾“恢复速度”和“数据安全性”，Redis 4.0 引入了工业界的最终答案：混合持久化 (Hybrid Persistence) 。
1. 混合持久化的工作原理
开启混合持久化后，AOF 在执行 Rewrite (重写) 时，会发生极其奇妙的变化：
- 子进程不再是把当前的键值对转化为
SET命令写入新的 AOF 文件。 - 而是直接将当前内存的数据以 RDB 的二进制压缩格式，写入到新的 AOF 文件的头部！
- 在子进程写 RDB 数据期间，主进程新接收到的写命令，依然以传统的 AOF 文本格式追加到这个文件的尾部。
最终形态的 AOF 文件： 前半段是 RDB 格式的压缩快照 + 后半段是 AOF 格式的增量命令。
2. 混合持久化的绝对优势
当 Redis 宕机重启，加载这个混合文件时：
-
先以极快的速度加载前半段的 RDB 二进制数据（解决了 AOF 恢复慢的问题）。
-
再执行后半段少量的 AOF 增量命令（解决了 RDB 丢数据的问题）。
简直是天作之合！
3. 如何开启？
在 redis.conf 中，确保 AOF 是开启的，然后加上这一行：
Properties
# 开启 AOF 与 RDB 的混合持久化
aof-use-rdb-preamble yes
三、 秋招实战演练：高频面试问答参考
🗣️ 面试官： “在你们的生产环境中，Redis 到底是用 RDB 还是 AOF？”
💡 满分话术参考：
“在实际生产中，我们绝对不会只单选某一种。
如果是纯缓存场景（比如商品分类列表，丢了可以马上从 MySQL 查回来重新缓存），为了极致的性能，我们会选择只开启 RDB。
但对于核心业务，我们采用的是 ‘AOF 为主，RDB 为辅’ 的策略，并在 Redis 4.0 之后开启了混合持久化。
我们将 AOF 设置为
everysec保证秒级数据安全。同时，虽然有了 AOF，我们依然会保留 RDB 功能，利用定时任务（比如每天凌晨 3 点）触发bgsave生成 RDB 快照文件，并同步到其他异地机房的云盘上。因为 RDB 文件极其紧凑，非常适合用于应对极其罕见的‘机房级物理灾难’的数据兜底恢复。”
学习总结
至此，关于“如何让单台 Redis 的数据绝对不丢”，你已经拥有了极其完备的理论体系和实战方案。这就是大型架构设计中最底层的“保底工程”。
