Redis 挂了数据会丢失吗？如何保证数据不丢？我：缓存而已，丢了就丢了…

Q: Redis 挂了数据会丢失吗？如何保证数据不丢？我：缓存而已，丢了就丢了…

面试考察点 基础掌握度：面试官不仅仅是想知道 RDB 和 AOF 的全称，更是想知道你是否理解 Redis 作为内存数据库，为什么需要持久化，以及两种方案各自的实现原理和触发机制。 对比分析能力：考察你能否从数据安全性、文件大小、恢复速度、

面试考察点

基础掌握度：面试官不仅仅是想知道 RDB 和 AOF 的全称，更是想知道你是否理解 Redis 作为内存数据库，为什么需要持久化，以及两种方案各自的实现原理和触发机制。
对比分析能力：考察你能否从数据安全性、文件大小、恢复速度、系统性能等多个维度，对 RDB 和 AOF 进行全面对比，并在实际场景中做出合理选型。
生产实践经验：是否能给出生产环境中的混合持久化方案（Redis 4.0+），以及如何根据业务特点（缓存场景 vs 存储场景）选择持久化策略。

核心答案

Redis 提供了两种核心持久化机制：RDB（Redis Database） 和 AOF（Append Only File），Redis 4.0 之后还支持 混合持久化。

对比维度	RDB	AOF
持久化方式	定时对整个内存数据做快照	记录每一条写命令到日志
数据安全性	可能丢失最后一次快照后的数据	最多丢失 1 秒数据（`everysec` 策略）
文件大小	二进制压缩，体积小	命令日志，体积大（重写后可缩小）
恢复速度	快（直接加载二进制）	慢（逐条回放命令）
系统性能影响	`fork` 子进程时有瞬间延迟	取决于 `fsync` 策略
适用场景	冷备、灾难恢复、从库同步	数据安全性要求高的主库

一句话结论：RDB 适合做 定期全量备份，恢复快但可能丢数据；AOF 适合做 实时增量备份，数据更安全但文件大、恢复慢。生产环境推荐 混合持久化（RDB + AOF）。

深度解析

一、RDB 持久化机制

RDB 是 Redis 的 默认持久化方式，它会在特定条件下将内存中的所有数据生成一个二进制快照文件（dump.rdb）。

上图展示了 RDB 持久化的完整流程。核心要点如下：

fork() 子进程：Redis 主进程调用 fork() 创建子进程，利用操作系统的 写时复制（Copy-On-Write，COW） 机制，子进程共享主进程的内存页。主进程继续处理客户端请求，只有在内存页被修改时才会真正复制。
生成 RDB 文件：子进程将内存数据以二进制格式写入一个临时文件，完成后替换旧的 dump.rdb。
主进程无阻塞：整个过程中，主进程可以正常处理读写请求，不会阻塞（仅在 fork 瞬间有短暂停顿）。

RDB 的触发方式：

自动触发：在 redis.conf 中配置 save 规则：

save 900 1      # 900 秒内有至少 1 次修改就触发
save 300 10     # 300 秒内有至少 10 次修改就触发
save 60 10000   # 60 秒内有至少 10000 次修改就触发

手动触发：执行 SAVE（阻塞主进程，不推荐）或 BGSAVE（后台执行，推荐）命令。

二、AOF 持久化机制

AOF 以 追加写日志 的方式，将每一条写命令记录到 appendonly.aof 文件中。

上图展示了 AOF 持久化的核心流程：

写入缓冲区：每条写命令先追加到内存中的 aof_buf 缓冲区。

刷盘策略：由 appendfsync 配置项决定何时将缓冲区数据写入磁盘：

策略	行为	数据安全	性能
`always`	每条命令都 `fsync`	最高，基本不丢数据	最差
`everysec`	每秒 `fsync` 一次	最多丢 1 秒数据（推荐）	折中
`no`	由操作系统决定刷盘	可能丢失较多数据	最好

三、AOF 重写机制

随着时间推移，AOF 文件会越来越大。Redis 提供了 AOF 重写（Rewrite） 机制来压缩文件。

AOF 重写的核心逻辑：

不是读取旧文件，而是直接读取当前 Redis 内存中的数据状态，用最少的命令重新生成一份 AOF 文件。
触发方式：
- 自动触发：auto-aof-rewrite-percentage 100（文件大小比上次重写后增长 100%）和 auto-aof-rewrite-min-size 64mb（文件最小达到 64MB）。
- 手动触发：执行 BGREWRITEAOF 命令。

四、混合持久化（Redis 4.0+）

Redis 4.0 引入了 RDB + AOF 混合持久化，结合了两者的优势。

开启方式：

# 开启 AOF
appendonly yes

# 开启混合持久化
aof-use-rdb-preamble yes

混合持久化的优势：

恢复速度快：RDB 部分可以快速加载全量数据。
数据安全性高：AOF 部分记录最新变更，保证数据完整性。
文件体积小：RDB 二进制格式比纯 AOF 命令日志更紧凑。

面试高频追问

追问一：RDB 的 fork() 为什么不会阻塞主进程？

利用 Linux 的 写时复制（COW） 机制，fork() 创建子进程时并不真正复制内存，只是共享父进程的内存页。只有当父进程修改某个内存页时，才会复制该页。所以 fork() 本身非常快（通常几毫秒），子进程生成 RDB 期间主进程可以正常服务。但如果内存数据量很大（比如几十 GB），fork() 可能会稍慢一些。
追问二：AOF 和 RDB 能不能同时开启？

可以同时开启。Redis 4.0 之前，两者独立运行，互不影响；Redis 4.0+ 开启混合持久化后，AOF 重写时会将 RDB 格式嵌入 AOF 文件，实现优势互补。实际生产中，建议同时开启，用 AOF 保证数据安全，用 RDB 做冷备。
追问三：Redis 宕机后恢复数据，优先加载哪个文件？

如果同时存在 RDB 和 AOF 文件，Redis 优先加载 AOF，因为 AOF 的数据完整性更高。如果只存在 RDB 文件，则加载 RDB。如果都存在但 AOF 损坏，可以使用 redis-check-aof 工具修复。

常见面试变体

变体一：”Redis 宕机数据会丢失吗？如何保证数据不丢？”
变体二：”生产环境 Redis 的持久化方案怎么选？”
变体三：”RDB 和 AOF 各自的优缺点是什么？”
变体四：”Redis 4.0 的混合持久化了解吗？解决了什么问题？”

记忆口诀

RDB：定期快照，体积小恢复快，但可能丢数据 —— “像拍照，抓住某个瞬间的状态”。

AOF：追加日志，数据更安全，但文件大恢复慢 —— “像录像，记录每一个动作”。

混合持久化：RDB 做底 + AOF 补增量，鱼与熊掌兼得。

总结

Redis 持久化是面试高频考点。RDB 是 定时全量快照，适合冷备和灾难恢复，恢复速度快但有数据丢失风险；AOF 是 实时增量日志，数据安全性更高但文件体积大、恢复慢。Redis 4.0+ 推荐使用 混合持久化，用 RDB 格式存储全量数据保证恢复速度，用 AOF 命令记录增量变更保证数据完整性，实现两者的优势互补。

Redis 挂了数据会丢失吗？如何保证数据不丢？我：缓存而已，丢了就丢了...