最近在整理《2025年Java面试宝典》时发现，Redis持久化机制几乎成了所有大厂面试的必考点。这里给大家分享个福利：2025年Java面试宝典（链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg 提取码: 9b3g），整理了Redis在内的20+技术栈高频考点，有需要的同学可以保存备用。
Redis持久化机制为什么重要？
作为程序员都知道，Redis是内存数据库，重启后数据会丢失。持久化机制就像给数据买了份保险，保证服务器宕机或重启时数据不丢失。这也是为什么面试官总爱问这个问题——既要懂原理，又要会根据业务选策略。
两种核心持久化方式
RDB持久化机制（快照模式）
简单理解就是给内存拍个照，把当前数据保存成二进制文件（dump.rdb）。咱们可以通过save或bgsave命令手动触发，也可以配置文件中的自动触发条件：
save 900 1 # 900秒内至少1次修改
save 300 10 # 300秒内至少10次修改
适合场景：需要做灾备恢复的场景。比如每天凌晨自动备份，恢复数据时直接加载rdb文件速度极快。
面试常问问题：
-
RDB生成快照时会阻塞主线程吗？
答：bgsave命令会fork子进程处理，主线程正常响应请求；但save命令会阻塞。 -
为什么生产环境不用默认配置？
答：默认的save 3600 1这种配置可能丢失1小时数据，需要根据业务调整频率。
AOF持久化机制（日志追加）
AOF就像记账本，每次写操作都会追加到日志文件。支持三种写回策略：
- always：每个命令都刷盘（安全但性能差）
- everysec：每秒刷盘（折中方案，推荐）
- no：由操作系统决定（可能丢数据）
性能优化技巧：
当AOF文件过大时，可以通过BGREWRITEAOF命令触发重写，用最简指令集重建日志文件。
混合持久化怎么选？
现在主流方案是RDB+AOF混合模式（4.0版本后支持）。启动时先加载RDB快照，再用AOF日志增量恢复。既保证了启动速度，又降低了数据丢失风险。
配置方式：
aof-use-rdb-preamble yes
面试常见坑点
- 主从架构下持久化配置：建议主库关闭持久化，从库开启（避免主库写磁盘影响性能）
- AOF重写期间断电怎么办：新版Redis通过临时文件+原子替换保证数据安全
- 物理机内存不足：fork子进程时如果内存翻倍可能触发OOM，建议预留50%内存
如果需要购买面试鸭会员获取更多面试真题解析，可以通过面试鸭返利网找我，立返25元！持续关注还能获取最新大厂面经合集。
真实故障案例
某电商平台大促期间Redis频繁崩溃，排查发现配置了save 60 10000的RDB策略，高峰期每分钟触发多次bgsave，导致CPU飙升。解决方案：改用AOF每秒刷盘，夜间低峰期做RDB备份。
掌握Redis持久化机制不仅要懂技术原理，更要结合业务场景做取舍。建议大家自己动手配置不同模式，用redis-benchmark测试性能差异，面试时才能讲出真实体感。
