redis持久化机制
2025年Java面试宝典已上传网盘：
https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码：9b3g（建议保存备用）
为什么需要redis持久化机制
当面试官问起Redis持久化机制时，最怕的就是把RDB和AOF两种模式混为一谈。我们先明确一个概念：持久化机制解决的是服务器重启后数据如何恢复的问题。想象你线上Redis突然宕机，如果没有任何持久化策略，内存里的数据就像没保存的Word文档——说没就没。
RDB快照模式
触发机制三兄弟
- 手动触发：用
save或bgsave命令。注意save会阻塞主线程，线上环境千万别用，这和开车时突然拉手刹一个道理 - 自动触发：配置文件里设置
save 900 1这种规则，表示900秒内有1次写操作就触发 - 特殊触发：执行flushall、主从全量复制时也会生成RDB文件
底层实现玄机
RDB本质上是通过fork子进程来写数据文件。这里有个面试坑：当Redis内存达到20GB时，fork操作可能会导致服务卡顿。因为fork要拷贝父进程的页表，在内存大的实例上，这个操作可能消耗数百毫秒。
AOF日志模式
写日志的三种姿势
- always：每个写命令都刷盘，数据最安全但性能最差
- everysec：默认配置，每秒批量刷一次
- no：交给操作系统决定，就像把重要文件扔给快递小哥还不买保价
重写机制妙用
当AOF文件膨胀到一定大小，Redis会启动重写进程。这个过程和RDB类似也是fork子进程，但会把多条命令合并成精简命令。比如对同一个key连续set 10次，最后只会保留最终值的那条命令。
RDB与AOF混合使用
现在主流的方案是混合持久化（Redis4.0+支持）。简单说就是RDB做全量备份，AOF做增量备份。恢复时先加载RDB的基准数据，再重放AOF的增量操作。这种组合拳既保证了恢复速度，又降低了数据丢失风险。
面试实战技巧
-
当被问到"如何选择持久化方式"时，可以这样答：
- 数据安全性要求极高 → AOF always模式
- 可接受分钟级数据丢失 → RDB
- 既要安全又要性能 → 混合模式
-
遇到"持久化导致服务卡顿怎么办"这类问题，重点讲fork机制的原理，以及如何通过控制实例内存大小来优化（比如单个实例不超过10GB）
-
被追问"主从架构下持久化策略"时，要区分主节点和从节点的配置差异。通常主节点关持久化，从节点开RDB，避免双重磁盘IO影响性能
小贴士：需要购买面试鸭会员的同学，通过面试鸭返利网找我可返25元，相当于用更低成本获取最新面试题库。持续关注我们的技术解析，助你在面试考场游刃有余！
