Redis持久化机制原理
（Redis持久化是面试高频考点，建议结合实战场景理解）
2025年Java面试宝典已整理完毕，涵盖Redis高频考点：
链接: <font color="blue">https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g</font>
提取码: 9b3g
Redis为什么需要持久化？
作为内存数据库，Redis将所有数据存储在内存中。但内存数据的致命问题是：服务器重启或宕机会导致数据丢失。这时候就需要Redis持久化机制将内存数据保存到磁盘，保障数据可靠性。这也是面试官必问的技术点。
Redis持久化的两种核心方案
RDB持久化机制
原理：像拍快照一样，在特定时间间隔将内存数据集生成二进制文件（dump.rdb）。触发条件包括：
- 配置文件中设置的
save规则（如900秒内有1次修改） - 执行
save或bgsave命令 - 主从复制时自动触发
核心特点：
- 使用写时复制技术（COW），父进程继续处理请求，子进程负责持久化
- 生成紧凑压缩的二进制文件，恢复速度快
- 可能丢失最后一次快照后的数据
（RDB文件结构示意图）
AOF持久化机制
原理：记录所有写操作命令（Append Only File），重启时重新执行这些命令恢复数据。提供三种写回策略：
- always：每次写命令都同步到磁盘（数据安全但性能差）
- everysec：每秒同步（推荐配置）
- no：由操作系统决定（可能丢失较多数据）
核心优势：
- 数据丢失风险更低（取决于同步策略）
- 可读的日志文件方便问题排查
- 支持自动重写压缩（bgrewriteaof）
RDB vs AOF如何选型？
| 维度 | RDB | AOF | |-----------|-------------------------|-----------------------| | 数据完整性 | 可能丢失分钟级数据 | 最多丢失秒级数据 | | 恢复速度 | 更快（二进制文件） | 较慢（需重放命令） | | 文件大小 | 小（压缩存储） | 大（需定期重写） | | 性能影响 | 写时复制影响内存和CPU | 频繁写入影响IO性能 | | 适用场景 | 允许数据丢失的缓存场景 | 数据安全性要求高的场景 |
（混合持久化示意图：Redis4.0+支持同时启用RDB+AOF）
生产环境实践建议
- 建议同时开启RDB和AOF（Redis4.0+版本）
- RDB备份频率建议每小时1次
- AOF重写阈值建议设置为当前AOF文件体积的2倍
- 监控持久化耗时，避免主线程阻塞
- 备份文件需要定期异地归档
需要购买面试鸭会员的同学，通过面试鸭返利网下单可返25元。本站持续更新Redis实战经验，欢迎访问mianshiyafanli.com获取更多面试技巧。
