文章目录
- [每日一篇高频面试题之 Redis 持久化](#每日一篇高频面试题之 Redis 持久化)
-
- 前言
- 一、面试经典原题
- [二、Redis 持久化概述](#二、Redis 持久化概述)
-
- [1. 持久化的作用](#1. 持久化的作用)
- [2. 两大持久化方案](#2. 两大持久化方案)
- [三、RDB 快照持久化](#三、RDB 快照持久化)
-
- [1. 核心原理](#1. 核心原理)
- [2. 触发方式](#2. 触发方式)
- [3. 优点](#3. 优点)
- [4. 缺点](#4. 缺点)
- [5. 适用场景](#5. 适用场景)
- [四、AOF 日志持久化](#四、AOF 日志持久化)
- [五、RDB 与 AOF 核心对比](#五、RDB 与 AOF 核心对比)
- 六、生产环境最佳实践
-
- [1. 混合持久化（Redis 4.0+ 推荐）](#1. 混合持久化（Redis 4.0+ 推荐）)
- [2. 单独使用场景](#2. 单独使用场景)
- [3. 线上避坑要点](#3. 线上避坑要点)
- 七、宕机恢复完整流程
- 八、高频灵魂追问
-
- [1. fork 子进程为什么会阻塞主线程？](#1. fork 子进程为什么会阻塞主线程？)
- [2. AOF 重写期间会丢失数据吗？](#2. AOF 重写期间会丢失数据吗？)
- [3. 为什么 AOF 恢复速度比 RDB 慢？](#3. 为什么 AOF 恢复速度比 RDB 慢？)
- [4. 可以关闭持久化吗？](#4. 可以关闭持久化吗？)
- [九、30 秒面试背诵版](#九、30 秒面试背诵版)
- 十、小测验
每日一篇高频面试题之 Redis 持久化
适合：春招 / 跳槽 / 转行 | 级别：Java 中初级开发 | 难度：⭐⭐⭐⭐ | 频率：极高
前言
关注公众号 "知识汲取者"【面试题】合集，可以每天抽空五分钟，趁着坐车、蹲坑、摸鱼等琐碎时间看一看，一来可以扎实基本功 ，二来可以随时熟悉面试题，让我们始终保持拥有随时可面的状态，时刻保持危机意识。
本专栏适合人群：
- 在职的开发人员
- 准备或正在跳槽的开发人员
- 未来想从事开发工作
一、面试经典原题
- Redis 为什么需要持久化？
- Redis 有哪两种持久化方式？RDB 和 AOF 原理、优缺点、使用场景分别是什么？
- RDB 和 AOF 如何配合使用？
- 持久化过程是否会阻塞主线程？如何优化？
- 宕机恢复数据流程是什么？
二、Redis 持久化概述
1. 持久化的作用
Redis 是内存数据库，数据默认存放在内存中，服务重启、机器宕机后内存数据会全部丢失。
持久化就是把内存数据定期写入磁盘，实现数据落地，保障数据不丢失，重启后可快速恢复数据。
2. 两大持久化方案
Redis 主流提供两种持久化机制：
- RDB（Redis Database）：快照持久化
- AOF（Append Only File）：日志追加持久化
三、RDB 快照持久化
1. 核心原理
在指定时间节点 ，把内存中全量数据 生成二进制快照文件（.rdb）保存到磁盘。
Redis 通过 fork() 创建子进程，由子进程完成快照写入，最大程度减少主线程阻塞。
2. 触发方式
（1）自动触发（配置规则）
在 redis.conf 中配置 save 规则，满足条件自动执行：
conf
# 示例：900秒内至少1个key变化、300秒内至少10个key变化、60秒内至少10000个key变化，触发RDB
save 900 1
save 300 10
save 60 10000（2）手动触发
save：主线程执行快照，全程阻塞，线上不推荐bgsave：fork 子进程执行快照，主线程不阻塞，线上常用
（3）其他触发
执行 flushall、主从复制全量同步时，也会自动触发 RDB。
3. 优点
- 文件是紧凑二进制格式，体积小，传输、备份、恢复速度快
- 恢复数据速度远快于 AOF
bgsave依靠子进程执行，对主线程影响小
4. 缺点
- 存在数据丢失风险：两次快照之间的数据，宕机会全部丢失
- 频繁快照会产生大量磁盘 IO，影响性能
- 数据量大时，
fork子进程会消耗内存，产生短暂阻塞
5. 适用场景
适合冷备份、全量数据迁移、对数据完整性要求不极致、允许少量数据丢失的场景。
四、AOF 日志持久化
1. 核心原理
以独立日志文件 形式，逐条记录客户端所有写命令（读命令不记录）。
Redis 执行一条写操作，就将命令追加到 AOF 日志末尾，重启时重新回放日志恢复数据。
2. 三种刷盘策略（appendfsync）
控制日志从内存缓冲区写入磁盘的时机，是 AOF 性能与数据安全的核心：
- always ：每执行一条写命令，立即刷盘。数据安全性最高，几乎不丢数据，性能最差。
- everysec （默认）：每秒刷一次盘。最多丢失1 秒数据，性能与安全性均衡，线上主流选择。
- no：交由操作系统自行调度刷盘。性能最好，宕机可能丢失大量数据。
3. AOF 重写（Rewrite）
产生原因
长期运行下，AOF 文件会不断膨胀（如多次修改同一个 key，会记录多条重复命令），文件体积过大、回放缓慢。
原理
Redis 开启子进程，读取当前内存数据，生成精简后的新命令集，替换旧 AOF 文件，压缩文件体积。
重写过程不会暂停正常写请求，新命令会继续追加到临时缓冲区。
4. 优点
- 数据安全性高，默认策略最多丢失 1 秒数据，可做到近乎不丢数据
- 日志文件是文本格式，可直接查看、手动修改
5. 缺点
- 同等数据量下，AOF 文件体积远大于 RDB
- 数据恢复时，需要逐条回放命令，速度比 RDB 慢很多
- 频繁刷盘、文件重写会带来一定 IO 压力
6. 适用场景
对数据完整性要求高，不允许大量数据丢失的业务场景。
五、RDB 与 AOF 核心对比
表格
| 对比项 | RDB | AOF |
|---|---|---|
| 存储内容 | 全量二进制数据快照 | 增量写命令日志 |
| 数据丢失 | 可能丢失大量数据 | 默认最多丢失 1 秒数据 |
| 文件体积 | 小，压缩率高 | 大，命令逐条记录 |
| 恢复速度 | 快 | 慢 |
| 性能影响 | 低（子进程执行） | 较高（持续刷盘 + 重写） |
| 格式 | 二进制，不可读 | 文本格式，可查看编辑 |
六、生产环境最佳实践
1. 混合持久化（Redis 4.0+ 推荐）
同时开启 RDB + AOF：
- 日常依靠 AOF 保障数据安全，最大程度减少数据丢失
- 定时执行 RDB 做全量快照，用于冷备份、数据迁移
- 重启恢复时：优先加载 RDB 快照，再回放 AOF 增量日志，兼顾速度与安全性
2. 单独使用场景
- 允许少量数据丢失、侧重备份与恢复：只开 RDB
- 数据绝对不能大量丢失：只开 AOF（选用
everysec策略）
3. 线上避坑要点
- 禁止使用
save命令，一律用bgsave，避免主线程阻塞 - 根据业务选择 AOF 刷盘策略，不建议使用
always（性能过低） - 合理配置 AOF 重写触发阈值，避免频繁重写
- 大内存实例注意
fork子进程带来的内存开销
七、宕机恢复完整流程
- Redis 重启，优先检查持久化文件
- 若同时开启 RDB+AOF：先加载 RDB 全量快照，再执行 AOF 增量日志
- 仅开启 RDB：直接加载
.rdb文件恢复数据 - 仅开启 AOF：逐条回放 AOF 日志文件恢复数据
- 无任何持久化文件：启动后为空库，数据完全丢失
八、高频灵魂追问
1. fork 子进程为什么会阻塞主线程？
fork 系统调用需要拷贝页表，内存越大，拷贝耗时越长，会造成短暂阻塞；子进程创建完成后，快照、日志操作均在子进程执行，不再阻塞主线程。
2. AOF 重写期间会丢失数据吗？
不会。重写过程中新的写命令会存入缓冲区，重写完成后一并追加到新文件，保证数据完整。
3. 为什么 AOF 恢复速度比 RDB 慢？
RDB 是直接加载二进制数据；AOF 需要逐条解析、执行日志中的写命令，步骤更多，耗时更长。
4. 可以关闭持久化吗？
纯缓存场景（数据可重新从数据源查询）可以关闭持久化，提升性能；有状态数据严禁关闭。
九、30 秒面试背诵版
Redis 持久化分为 RDB 快照和 AOF 日志两种方式。RDB 定时生成全量二进制快照，文件小、恢复快，但会丢失时段内数据；AOF 持续追加写命令日志，数据安全性高，默认最多丢 1 秒数据，但文件大、恢复慢。生产环境推荐两者同时开启，AOF 保障实时数据安全，RDB 做定时冷备份，宕机重启优先加载 RDB 再回放 AOF，兼顾性能与数据安全。
十、小测验
- 简述 RDB 和 AOF 的原理及核心优缺点？
- AOF 有哪三种刷盘策略，区别是什么？
- 什么是 AOF 重写，作用是什么？
- 生产环境为什么建议 RDB + AOF 配合使用？
点赞 + 收藏，每天 5 分钟，面试稳稳上岸 ✨