一、先理清核心前提：Redis 为什么要持久化？
我们项目里 Redis 主要做热点数据缓存，正常缓存逻辑是：数据库存全量数据，Redis 放高频访问数据。 但如果 Redis 宕机、服务器重启，内存里缓存数据会全部丢失：
- 短时间大量请求击穿缓存，直接打满 MySQL，引发数据库雪崩；
- 若 Redis 存了部分临时状态、计数器、分布式锁记录，丢数据会业务异常。 持久化本质：把内存中的缓存数据落地磁盘，重启后自动加载恢复缓存，降低雪崩风险。
Redis 提供两套独立持久化方案：RDB（快照持久化） 、AOF（日志追加持久化），可以单独开，也能同时开启。
二、RDB 快照持久化（全量持久化）
1. 核心原理
定期把当前 Redis 内存中全部缓存数据生成一份二进制快照文件（dump.rdb）保存到磁盘。 触发分两种方式：
-
自动触发（配置规则） redis.conf 配置
save 秒数 改动次数，例如：save 900 1 # 900秒内至少1个key修改，生成RDB
save 300 10 # 300秒内至少10个key修改，生成RDB
save 60 10000 # 60秒内一万次修改，强制快照 -
手动触发
SAVE：主线程阻塞，全量刷盘，大数据量缓存会卡死服务，线上缓存环境几乎不用；BGSAVE：fork 子进程，子进程负责写 RDB 文件，主线程继续处理缓存读写请求，线上默认使用。
2. 落地流程（BGSAVE）
- Redis 主线程调用
fork()创建子进程； - 子进程复制父进程内存数据（写时复制 COW 机制）；
- 子进程将完整缓存数据写入临时 rdb 文件；
- 写入完成替换旧 dump.rdb，父进程正常对外提供缓存服务。
3. 缓存场景优缺点
✅ 优点：
- 文件体积小、二进制压缩，重启加载缓存速度极快；
- 子进程操作磁盘，主线程阻塞时间极短，对缓存读写性能影响小；
- 适合做定时备份，比如凌晨低峰全量备份缓存热点数据。
❌ 缺点：
- 两次快照之间的数据会丢失：比如配置 5 分钟一次 RDB，宕机最多丢 5 分钟缓存修改数据；
- 大数据量缓存下 fork 子进程会占用大量内存，服务器内存不足时容易卡顿；
- 只能全量存储，增量修改无法单独记录。
4. 缓存业务适用场景
数据允许少量丢失、追求快速重启恢复缓存：商品基础缓存、用户基础信息缓存、分类热点数据。
三、AOF 追加日志持久化（增量持久化）
1. 核心原理
记录 Redis 每一条修改缓存的写命令（set/del/hset 等，只读命令不记录），以文本形式追加到 aof 文件。 重启 Redis 时，重新从头到尾执行 AOF 里所有命令，还原完整缓存数据。
2. 三种刷盘策略（核心配置 appendfsync）
这是做缓存时调优的重点，直接平衡性能和数据丢失量：
appendfsync always每次写缓存命令执行完，立刻刷磁盘。
- 零数据丢失；
- 磁盘 IO 极高，缓存 QPS 直接暴跌，线上缓存几乎禁用。
appendfsync everysec（默认推荐） 每秒把缓冲区指令刷一次磁盘。
- 最多丢失 1 秒内缓存写入数据；
- IO 压力适中，缓存性能损失很小，绝大多数业务缓存选用。
appendfsync no交给操作系统自动刷盘，由 OS 控制时机。
- 丢失数据不可控，可能几十秒；
- Redis 性能最好，但数据风险高，不建议缓存场景使用。
3. AOF 重写机制（解决文件膨胀）
如果缓存频繁更新同一个 key（比如商品库存不停增减），AOF 会堆积大量冗余命令，文件越来越大，重启加载极慢。 Redis 提供BGREWRITEAOF后台重写：
- fork 子进程，读取当前内存缓存数据；
- 用最简命令生成新 AOF 文件（比如 100 次 incr 合并成一条 set）；
- 新文件写完替换旧大文件，大幅压缩体积。 可配置自动重写阈值，达到文件大小自动触发，不用人工干预。
4. 缓存场景优缺点
✅ 优点：
- 数据丢失极少，everysec 策略最多丢 1 秒缓存数据，防雪崩能力更强；
- 文本日志，可手动打开修复、恢复误删缓存 key；
- 增量记录，不用全量拷贝内存，fork 开销比高频 RDB 小。
❌ 缺点：
- AOF 文件体积远大于 RDB，缓存重启加载速度慢；
- 持续磁盘 IO，高并发写入缓存场景会有轻微性能损耗。
5. 缓存业务适用场景
缓存数据不能大量丢失：订单临时缓存、支付状态、秒杀库存、用户会话 token。
四、线上缓存标准方案：RDB + AOF 同时开启（生产推荐）
执行逻辑
- 日常增量持久化靠 AOF，保证宕机最多丢 1 秒缓存；
- 定时 BGSAVE 生成 RDB 全量快照，做冷备份；
- Redis 重启时优先加载 AOF 文件（数据更完整），AOF 损坏才降级加载 RDB 快照。
为什么缓存要双开？
- 纯 RDB：丢数据风险高，流量高峰宕机极易缓存击穿；
- 纯 AOF：文件过大，长期运行重启恢复缓存耗时很长；
- 两者搭配：兼顾数据安全 + 快速恢复缓存。
五、作为业务开发，使用 Redis 缓存持久化的实操注意点（面试加分项）
- 缓存冷热分离，避免无意义持久化 临时短期缓存（过期时间几秒、临时计算中间值）可以不参与持久化，减少磁盘 IO；只有重要热点业务缓存开启落地。
- 服务器内存规划 开启持久化会 fork 子进程，内存占用翻倍，Redis 部署机器内存预留 50% 以上，防止 OOM。
- 磁盘分离 RDB/AOF 文件不要和 MySQL、系统日志共用一块磁盘，避免 IO 争抢拖慢缓存读写。
- 持久化不代表高可用 持久化只解决单节点宕机缓存恢复；集群、主从、哨兵才解决节点故障转移，持久化是兜底，不是高可用方案。
- 主从架构持久化规范 线上主从缓存：主节点开启 AOF+RDB，从节点建议关闭持久化。如果从节点落盘，主节点宕机切从后，两份持久化文件会造成数据冲突，增加维护成本。
- 缓存雪崩兜底补充 就算开了持久化，大流量场景仍要配套：缓存过期时间打散、互斥锁、空值缓存、多级缓存，持久化只是最后一道数据兜底防线。
六、快速总结（面试收尾简洁版）
Redis 缓存持久化分为 RDB 快照和 AOF 日志两种：
- RDB 是全量二进制快照，恢复快、丢失数据多，适合定时备份；
- AOF 增量记录写命令，数据更安全，默认每秒刷盘仅丢 1 秒数据；
- 生产环境缓存推荐双开，重启优先加载 AOF 保证数据完整；
- 持久化用来宕机恢复缓存，缓解缓存雪崩，同时要配合内存、磁盘、主从架构做优化。