Redis 缓存的数据持久化方案讲解

一、先理清核心前提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主线程阻塞全量刷盘大数据量缓存会卡死服务线上缓存环境几乎不用BGSAVEfork 子进程子进程负责写 RDB 文件主线程继续处理缓存读写请求线上默认使用。2. 落地流程BGSAVERedis 主线程调用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 争抢拖慢缓存读写。持久化不代表高可用持久化只解决单节点宕机缓存恢复集群、主从、哨兵才解决节点故障转移持久化是兜底不是高可用方案。主从架构持久化规范线上主从缓存主节点开启 AOFRDB从节点建议关闭持久化。如果从节点落盘主节点宕机切从后两份持久化文件会造成数据冲突增加维护成本。缓存雪崩兜底补充 就算开了持久化大流量场景仍要配套缓存过期时间打散、互斥锁、空值缓存、多级缓存持久化只是最后一道数据兜底防线。六、快速总结面试收尾简洁版Redis 缓存持久化分为 RDB 快照和 AOF 日志两种RDB 是全量二进制快照恢复快、丢失数据多适合定时备份AOF 增量记录写命令数据更安全默认每秒刷盘仅丢 1 秒数据生产环境缓存推荐双开重启优先加载 AOF 保证数据完整持久化用来宕机恢复缓存缓解缓存雪崩同时要配合内存、磁盘、主从架构做优化。