2025年Java面试宝典 最新版已更新，包含Redis高频面试题解析，点击链接领取（提取码：9b3g）
Redis持久化机制有几种方式？优缺点是什么？怎么实现的？RDB和AOF的区别
Redis作为互联网公司的必用中间件，持久化机制是面试必考题。今天我们从实现原理、使用场景、优缺点对比三个维度，帮你彻底搞懂RDB和AOF这两种持久化方式。
为什么需要Redis持久化？
内存数据库最怕的就是断电丢数据。比如某电商平台的购物车数据如果全存在Redis里，突然宕机导致数据丢失，用户体验直接崩塌。Redis通过RDB快照和AOF日志两种持久化方案，确保数据可恢复。这两种方案用得好，能实现秒级数据恢复，用得不好可能引发灾难性故障。
RDB持久化详解
实现原理：
简单理解为给内存拍快照。当满足save 900 1这样的配置条件（900秒内有1次写操作），或者执行SAVE/BGSAVE命令时，Redis会通过fork子进程把内存数据写入dump.rdb文件。
核心优势：
- 性能杀手锏：子进程方式持久化，主进程继续服务（写时复制技术）
- 灾难恢复快：20G数据恢复只需加载一个文件，比AOF重放快10倍
- 节省磁盘空间：二进制压缩存储，比AOF日志小得多
致命缺陷：
- 最后一次持久化后的数据可能丢失（比如5分钟持久一次，服务器宕机就丢5分钟数据）
- 数据量太大时fork操作会阻塞主线程（比如100G内存fork耗时可能到秒级）
AOF持久化详解
实现原理：
记录所有写操作命令（增删改），以追加方式写入appendonly.aof文件。支持三种写回策略：
- Always：每个命令都刷盘（数据零丢失，性能差）
- Everysec：每秒刷盘（最多丢1秒数据，生产常用）
- No：交给操作系统决定（可能丢大量数据）
独特优势：
- 数据安全天花板：Always模式能做到零数据丢失
- 可读性强：AOF文件是文本格式，方便人工分析
- 容错性好：自带
redis-check-aof工具修复损坏文件
性能痛点：
- 文件体积会无限增长（需要定期执行AOF重写）
- 恢复速度比RDB慢（特别是大文件）
- 开启AOF后QPS会比纯内存操作下降约20%
RDB vs AOF核心区别对比表
| 对比维度 | RDB | AOF | |-----------------|------------------------------|------------------------------| | 数据完整性 | 可能丢失分钟级数据 | 最高可保障零数据丢失 | | 恢复速度 | 快（直接加载数据文件） | 慢（需逐条执行命令） | | 磁盘占用 | 小（二进制压缩） | 大（文本日志积累） | | 对主线程影响 | fork时可能阻塞 | 刷盘策略决定阻塞程度 | | 适用场景 | 允许数据丢失的缓存场景 | 金融级数据安全要求的场景 |
生产环境怎么选？
黄金组合方案：
同时开启RDB和AOF（注意不是二选一！）。这样既能用RDB做冷备快速恢复，又能用AOF保证数据安全性。当两种文件同时存在时，Redis 4.0+版本会优先加载AOF文件。
调优技巧：
- RDB配置
save 3600 1降低持久化频率 - AOF使用
everysec策略平衡性能与安全 - 部署脚本监控
aof_rewrite_in_progress防止重写卡死 - 使用
bgrewriteaof命令在业务低峰期手动触发重写
如果需要购买面试鸭会员，记得通过面试鸭返利网找我，可返现25元。我们整理了20+互联网大厂的Redis真实配置方案，助你避开生产环境中的那些坑。
高频面试考点
-
AOF重写原理（面试官最爱的底层原理题）
通过创建子进程生成新的AOF文件，合并冗余命令。比如对同一个key的10次修改，最终只需保留最后一次set命令。 -
混合持久化（Redis 4.0新增功能）
AOF重写时会用RDB格式保存当前数据快照，后续增量命令用AOF格式追加。这样恢复时既有RDB的速度，又有AOF的完整性。 -
主从架构下的持久化策略
建议在从节点做持久化，避免主节点磁盘IO影响服务性能。但要注意如果从节点重启，需要先连接主节点做全量同步。
