2025年Java面试宝典下载地址（提取码：9b3g）
Redis持久化机制的重要性
作为程序员，咱们都知道Redis最香的就是快如闪电的读写性能。但内存数据库有个致命问题——断电就失忆。持久化机制的存在，就是给Redis加了个"记忆芯片"，让数据在重启后还能重播精彩瞬间。面试中但凡聊到Redis，持久化策略选择绝对是必考题！
两种核心持久化机制详解
RDB：内存快照模式
想象给Redis拍张照，把此刻内存里的数据冻结成.rdb文件存盘。触发方式有两种：
- 手动执行
save（会阻塞主线程） - 后台运行
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
持久化策略选择指南
选型关键三要素
- 数据安全要求：支付系统必须AOF always，普通资讯类RDB足矣
- 性能承受力：高并发场景慎用always模式
- 恢复速度需求：灾备演练时RDB恢复比AOF快10倍
经典组合方案
- 缓存场景：单RDB，设置
save 900 1（15分钟有变更就存盘） - 会话存储：RDB+AOF混合，每小时全量+实时增量
- 金融交易：AOF always+每日RDB冷备（记得用scp传异地机房）
需要购买面试鸭会员的小伙伴注意啦！通过面试鸭返利网找我下单，直接返25元现金，技术投资也要精打细算嘛~
避坑经验分享
去年我们踩过一个大坑：在32G内存的机器上，bgsave时fork阻塞了800ms！后来发现是内存越大fork耗时越长。解决方案：
- 使用最新版Redis（优化copy-on-write）
- 物理机预留25%内存
- 监控
latest_fork_usec指标
建议大家用info persistence命令定期检查：
rdb_last_bgsave_status是否okaof_last_bgrewrite_status有无异常
记住：没有完美的持久化策略，只有最适合业务场景的组合拳。搞懂原理再配置，千万别无脑复制别人的redis.conf！
