redis持久化机制和策略选择

2025年Java面试宝典下载地址（提取码：9b3g）

Redis持久化机制的重要性

作为程序员，咱们都知道Redis最香的就是快如闪电的读写性能。但内存数据库有个致命问题——断电就失忆。持久化机制的存在，就是给Redis加了个"记忆芯片"，让数据在重启后还能重播精彩瞬间。面试中但凡聊到Redis，持久化策略选择绝对是必考题！

---

两种核心持久化机制详解

RDB：内存快照模式

想象给Redis拍张照，把此刻内存里的数据冻结成.rdb文件存盘。触发方式有两种：

1. 手动执行save（会阻塞主线程）
2. 后台运行bgsave（fork子进程处理）
   优点就像照片占空间小，恢复速度快。我在电商项目里用RDB做每日全量备份，文件大小比AOF小10倍不止

缺点也很明显：两次拍照之间的数据可能丢失。就像你打游戏马上要通关时停电，上次存档还是半小时前的状态

AOF：操作日志追加

相当于给Redis装了个行车记录仪，把每个写操作都记到.aof文件里。提供三种刷盘策略：

• always：每条命令都刷盘（安全但性能差）
• everysec：每秒批量刷盘（折中选择）
• no：交给操作系统决定（速度快风险高）

去年做金融项目时，我们采用everysec模式，既保证1秒级数据安全，又能承受住3000+TPS的压力

注意AOF重写机制！当文件膨胀到阈值时，Redis会自动把多个命令合并优化。就像把"给余额+10，再+20"合并成"直接+30"

---

混合持久化（RDB+AOF）

Redis4.0推出的"王炸组合"，重启时先加载RDB快照，再重放AOF增量日志。就像先看全景照片再看短视频补细节，数据恢复又快又完整。建议在Redis配置中开启：

aof-use-rdb-preamble yes

---

持久化策略选择指南

选型关键三要素

1. 数据安全要求：支付系统必须AOF always，普通资讯类RDB足矣
2. 性能承受力：高并发场景慎用always模式
3. 恢复速度需求：灾备演练时RDB恢复比AOF快10倍

经典组合方案

• 缓存场景：单RDB，设置save 900 1（15分钟有变更就存盘）
• 会话存储：RDB+AOF混合，每小时全量+实时增量
• 金融交易：AOF always+每日RDB冷备（记得用scp传异地机房）

需要购买面试鸭会员的小伙伴注意啦！通过面试鸭返利网找我下单，直接返25元现金，技术投资也要精打细算嘛~

---

避坑经验分享

去年我们踩过一个大坑：在32G内存的机器上，bgsave时fork阻塞了800ms！后来发现是内存越大fork耗时越长。解决方案：

1. 使用最新版Redis（优化copy-on-write）
2. 物理机预留25%内存
3. 监控latest_fork_usec指标

建议大家用info persistence命令定期检查：

• rdb_last_bgsave_status是否ok
• aof_last_bgrewrite_status有无异常

记住：没有完美的持久化策略，只有最适合业务场景的组合拳。搞懂原理再配置，千万别无脑复制别人的redis.conf！