Redis持久化机制原理
2025年最新Java面试宝典已更新，包含Redis高频考点解析：
🔗 网盘链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g
很多同学在面试中被问到Redis持久化机制时，总感觉概念容易混淆。今天我们就用最直白的方式，拆解RDB和AOF两种持久化方案的核心原理和适用场景。
一、RDB持久化：快照式存储
实现原理：
Redis通过fork子进程的方式，将内存数据以二进制形式dump到磁盘（默认文件dump.rdb）。这个过程中父进程继续处理请求，子进程负责持久化操作，利用操作系统的写时复制（Copy-On-Write）机制保证数据一致性。
触发方式：
- 手动执行
SAVE（阻塞）或BGSAVE（后台执行） - 配置自动触发规则，例如
save 60 10000表示60秒内有1万次写入则触发 - 主从复制时自动触发
优点：
- 数据恢复速度快（二进制文件直接加载到内存）
- 适合大规模数据冷备份
- 生成紧凑的单一文件便于传输
缺点：
- 可能丢失最后几分钟数据（取决于备份频率）
- 大数据量时fork过程可能导致短暂卡顿
二、AOF持久化：日志式记录
实现原理：
记录所有修改命令（默认不开启），通过三种写回策略平衡性能与安全性：
- Always：每条命令都刷盘（强一致，性能最低）
- Everysec：每秒批量刷盘（推荐平衡方案）
- No：由操作系统决定刷盘时机（性能最高，风险最大）
文件重写机制：
为避免AOF文件过大，Redis会定期根据内存数据重建精简命令集。例如将10万次incr count合并为set count 100000，大幅减少文件体积。
优点：
- 数据丢失风险低（最高配置下只会丢失1秒数据）
- 可读性强的日志文件便于问题追溯
- 支持紧急情况下的误操作修复
缺点：
- 文件体积通常大于RDB
- 数据恢复速度慢于RDB
三、混合持久化方案
Redis 4.0版本开始支持RDB+AOF混合模式，结合两者优势：
- 使用AOF记录实时操作
- 定期生成RDB全量快照
- 重启时先加载RDB快照，再重放增量AOF日志
四、如何选择持久化方案
根据业务场景选择：
- 高QPS且允许少量数据丢失：RDB + 适当备份间隔
- 交易类敏感数据：AOF(Everysec) + 定期RDB备份
- 7x24关键服务：混合持久化 + 主从复制
特别说明：无论选择哪种方案，都要配合监控系统关注以下指标：
- 持久化文件生成耗时
- 最后一次成功备份时间
- AOF重写缓冲区使用率
如果大家需要购买面试鸭会员，可以通过面试鸭返利网联系我，可额外返利25元。这里整理了各大厂最新面试真题解析，帮助大家高效备战：
五、面试应答技巧
当面试官问及Redis持久化机制时，建议采用"总分总"结构：
- 先概括两种机制的特点
- 对比两者的实现差异和适用场景
- 结合实际案例说明选择依据
- 补充说明新版混合模式的改进
记住这个万能话术："在电商秒杀场景中，我们采用RDB做每日全量备份，同时开启AOF每秒刷盘，这样既能快速恢复数据，又能最大限度防止订单数据丢失。"
