1. 先搞清楚Redis 持久化模型到底在解决什么问题1.1 内存数据库的“先天短板”Redis 之所以快核心在于数据全部落在内存里。内存的随机读写延迟在几十到一百纳秒级而磁盘哪怕是最快的 NVMe 固态延迟也在几十微秒两者差了三个数量级。所以 Redis 不可能把每个写操作都同步刷到磁盘否则它就和普通数据库没什么区别了。但内存有一个致命短板掉电即失。进程正常退出时可以优雅收尾可进程崩溃、机器重启、机房断电这种事从来不会提前打招呼。如果没做持久化重启后的 Redis 就是一台“失忆服务器”之前存的所有数据全没了。很多业务场景里 Redis 只是纯缓存缓存丢了问题不大回源数据库重新加载就行。可一旦你在 Redis 里放了分布式锁、订单状态、幂等标记、活动计数这类数据它们往往直接影响业务正确性。更极端的情况有人把 Redis 当数据库用那重启丢数据就是事故。所以我经常跟团队新人说把数据放进 Redis 之前第一件事不是写代码而是想清楚一个问题——数据丢了能不能接受能接受默认配置就够用不能接受就得认真研究 RDB、AOF 以及它们背后共同的机制 fork。1.2 三类模型快照、日志、混合从架构视角看RDB 和 AOF 代表了两种非常经典的持久化模型。RDB 是“快照模型”每隔一段时间把内存里的完整数据集拍照存到磁盘恢复时把这张照片直接加载回来。AOF 是“日志模型”把所有写操作按顺序记录成追加日志恢复时把日志从头到尾重放一遍相当于重演每一次写入。这两种模型各有优劣快照恢复快、文件紧凑但两次快照之间的数据会丢日志丢失窗口小能恢复到最后一次操作附近但文件会膨胀、恢复也慢。于是 Redis 后来把两者组合成了“混合模型”先用快照打底再追加一小段日志兼顾速度和安全性。理解了这个分类后面所有配置选项和故障排查就都有了主线。这里还要提前点出第三个关键词——fork。RDB 的 bgsave 和 AOF 的 bgrewriteaof都是通过 fork 子进程去做落盘从而避免阻塞主线程。所以不懂 fork就没法真正理解 Redis 持久化的性能边界也解释不了生产环境里那些“莫名其妙卡一下”的毛刺。这一篇我会专门用一整节把 fork 讲透。1.3 持久化在 Redis 技术栈里的位置持久化不是孤立存在的它是主从复制、哨兵、集群这些高可用方案的地基。举个例子主从同步时从节点要从主节点拿一份全量数据这个全量数据本质上就是一份 RDB 快照如果主节点没开持久化崩溃重启后数据是空的从节点同步过去之后也会变成空库灾难会顺着主从链路扩散。在缓存治理里持久化还承担着“防冷启动冲击”的作用。Redis 重启后如果缓存全空大量请求会同时回源数据库这种压力放大比单纯的缓存穿透要可怕得多。打开持久化至少能让热数据快速恢复数据库不至于被打爆。这也是为什么 Redis 作为中间件部署时持久化配置必须和业务方一起确认而不是让运维拍脑袋定。2. RDB 持久化全量快照是如何运转的2.1 触发方式和配置细节RDB 的实现思路是定期把内存中的数据集写入 dump.rdb 文件。触发方式分为手动和自动。手动触发有两条命令save 和 bgsave。save 是同步的执行期间主进程直接做快照所有客户端请求都会被阻塞数据量大时能感受到明显的停顿bgsave 是后台保存主进程 fork 出一个子进程子进程负责写文件父进程继续服务这是生产环境实际会用的方式。我本机做过测试100 万 key 的实例save 阻塞大概 3 秒bgsave 对主线程基本无感只有 fork 那一下有毫秒级抖动。所以手动触发几乎永远该用 bgsavesave 只在测试和排障时用。自动触发看 redis.conf 里的 save 配置。save 3600 1表示 3600 秒内至少有 1 次写操作就触发save 300 100表示 300 秒内至少有 100 次写操作触发save 60 10000表示 60 秒内至少有 10000 次写操作触发。这几个条件只要满足一个就会执行 bgsave。这里有个常见误解不是到点就存而是“时间窗口内发生了足够多的写操作”才存。也有新手以为三个条件会同时叠加判断实际上 Redis 是按配置顺序从上往下检查只要有一个满足就触发。如果你希望完全关闭 RDB可以配置save 。但我建议别彻底关闭哪怕有 AOFRDB 文件也是很好的全量备份和灾备载体。2.2 RDB 文件结构与加载流程RDB 文件是二进制格式内部包含文件头、数据集元信息、各个数据库的键值对以及文件尾部的校验信息。Redis 加载时会做完整性校验校验失败会直接拒绝启动。恢复流程很简单把 dump.rdb 放进配置的 dir 目录指定 dbfilename重启 Redis 会自动加载。有一个关键点经常被忽略如果同时开了 AOFRedis 启动时会优先加载 AOF而不是 RDB。准确说Redis 启动逻辑是“优先尝试加载 AOFAOF 不存在才加载 RDB”因为 AOF 里通常包含更新的数据。所以如果你改了 AOF 配置却拿旧 RDB 去覆盖最后启动加载的可能还是 AOF 文件里的数据这一点在排障时要格外留意。另外RDB 加载过程是阻塞式的。加载期间 Redis 不能对外服务数据量越大阻塞越久。一台 10GB 数据量的实例从磁盘加载可能要几十秒到几分钟。线上主节点重启后客户端会大面积超时所以生产环境常用主从架构从节点先加载恢复确认无误后再切换流量或者用哨兵把请求切到健康节点。2.3 RDB 的优点和缺陷RDB 的优点很突出文件紧凑、恢复快、迁移方便。做跨机房灾备或者数据迁移时直接拷一份 dump.rdb改个路径就能在另一台机器上恢复这个操作我做过很多次非常稳。缺陷也同样突出。第一层是丢数据窗口大两次快照之间写入的数据崩溃时会整体丢失。比如凌晨 2 点刚做完快照早上 8 点宕机这 6 小时的数据全没了。第二层是 fork 成本为了不阻塞主线程bgsave 必须 fork 子进程而 fork 在内存越大、写入越频繁的实例上越容易引发卡顿和内存上涨。很多团队只看到 RDB “丢数据多”没意识到 fork 也经常是线上偶发卡顿的来源。这也是我每次讲持久化都要把 fork 单拎出来的原因。3. AOF 持久化追加日志与混合持久化3.1 AOF 记录了什么fsync 怎么选AOFAppend Only File不保存某个时间点的全量快照而是把每一条修改类命令以 RESP 协议格式追加到文件末尾。比如执行set user:1 zhangsanAOF 文件里就多一条对应记录执行incr login:count记录的也是命令本身。恢复时Redis 从头到尾逐条执行这些命令相当于把数据重放一遍。既然要记录日志就不能每条命令都立刻刷盘否则 IO 会变成瓶颈。关键配置是 appendfsync有三个值。always每条命令执行后都 fsync安全等级最高但性能下降最明显everysec每秒把缓冲区的数据刷一次盘最多丢 1 秒数据是生产环境最常见的配置no把刷盘时机完全交给操作系统性能最好但宕机时可能丢几十秒甚至更久的数据因为操作系统不保证立即写回。提醒一句不要为了“压性能”把 appendfsync 改成 no。我做线上排障时遇到过几次主节点重启后数据对不上最后都发现是有人为了性能改了 no。everysec 的丢失窗口和性能表现对绝大多数业务都够用no 的那点性能收益不值得冒风险。补充一个细节everysec 模式下的 fsync 是 Redis 放到后台线程去做的并不会阻塞主线程处理命令。真正要警惕的是磁盘突然变慢比如云磁盘 IOPS 被限流这时后台 fsync 跟不上AOF 缓冲区会持续积压最终可能反过来拖慢写命令。3.2 AOF 重写机制日志为什么不会无限涨AOF 日志天生会膨胀。比如你对同一个 key 执行 100 次incrAOF 里就多了 100 条命令但恢复时只需要一条 set 命令就能还原最终值。中间过程全是冗余。文件大了不仅占磁盘恢复时重放也慢。所以 Redis 提供了重写机制 bgrewriteaoffork 子进程基于当前内存里的最终状态重新生成一份最小 AOF再把重写期间新产生的命令追加进去。自动重写的触发条件是两个配置auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size。默认是当前文件体积超过上次重写后体积的 100%且体积超过 64MB 时触发。比如上次重写完是 100MB文件长到 200MB 就会再来一次。理解了这一点你就不会看到 AOF 文件忽大忽小的时候觉得是出 bug 了。在 AOF 重写期间主进程会继续处理写命令这些新命令会暂时存放在内存缓冲区里等子进程写完新文件再由主进程把缓冲区的命令追加到新文件尾部。所以重写期间内存会有一定额外开销“重写时内存上涨”属于正常现象。3.3 混合持久化RDB 打底加 AOF 增量从 Redis 4.0 开始引入了混合持久化配置项是 aof-use-rdb-preamble。开启之后AOF 重写不再生成纯文本命令日志而是先在文件头部写一段 RDB 格式的全量快照再把重写期间的新命令以 AOF 格式追加在后面。这样加载时先快速导入 RDB 全量数据再重放少量新命令恢复速度接近 RDB安全等级接近 AOF。混合持久化在生产环境里我是强烈建议开的。它基本解决了纯 AOF “恢复慢”和纯 RDB “丢数据多”这两个老大难问题。但要注意生成的 .aof 文件是 RDB 格式开头的混合文件不能当纯文本直接 cat也别指望老版本的工具能正确处理它。跨大版本迁移时老 Redis 实例可能识别不了新版本生成的混合文件迁移前最好先降级为纯 AOF 或者重新做一次全量备份。3.4 AOF 损坏与修复AOF 文件在宕机或磁盘故障时可能损坏。Redis 启动加载时如果发现文件中间有不完整或非法记录会直接启动失败报类似Bad file format reading the append only file的错误。这时候不要慌先备份原文件再执行redis-check-aof --fix appendonly.aof工具会把尾部不完整的数据截掉然后就能启动了。代价是截掉之后的数据丢失这是没法补的。所以养成一个好习惯定期备份 AOF/RDB 文件每次修改持久化相关配置前都先备份当前文件。Cron 定时拷贝到独立存储成本不高但关键时刻能救命。遇到损坏文件修复工具也不是万能的头部损坏时它往往无能为力那时候就只能靠备份了。4. Fork 的本质持久化背后的进程机制4.1 fork 到底复制了什么很多人提到 fork 就以为是把父进程的内存全部复制一份这个理解是错的。fork 是 Unix/Linux 的系统调用调用后生成一个与父进程几乎相同的子进程。所谓“相同”是地址空间看起来一样但底层并没有把物理内存数据全部拷贝一遍。真正做的是复制页表。系统为子进程复制一套页表结构并把所有物理内存页标记为只读。父进程和子进程此时共享同一批物理页面。只要双方都不修改内存共享可以一直持续但如果其中一方要写某个页就会触发缺页异常操作系统此时才真正复制这一页内核再解除只读标记。这就是写时复制也就是 Copy On Write简称 COW。理解这个机制你就能回答一个问题为什么 fork 一个几十 GB 内存的 Redis 进程不会真的瞬间复制出几十 GB 内存因为它只复制了页表物理内存还是那批。但页表本身也可能很大数据库实例的内存页多到一定程度复制页表同样要花时间这就是 fork 耗时的由来。4.2 fork 之后为什么会有内存上涨Redis 主进程是单线程执行命令的bgsave 不能自己一边读数据一边写文件那会阻塞太久。它的做法是 fork 子进程让子进程把数据集写到磁盘。fork 过程本身发生在主线程里虽然只是复制页表但页表量大时主线程同样会被短暂卡住表现为命令延迟出现毛刺。更隐蔽的问题是 fork 之后的 COW。父进程继续接受写入时因为内存页被标记为只读每次修改都会触发缺页复制。如果写入非常频繁Redis 会为所有被修改的页面创建副本常驻内存 RSS 就会慢慢涨起来极端情况下接近原有内存的两倍。这不是内存泄漏是 COW 的预期开销但如果不了解很容易被当成故障去排查。我见过一套 8GB 数据量的实例bgsave 期间 RSS 涨到 16GB 左右把监控告警都打炸了。最后定位到是 COW 正常现象但从此团队知道了做持久化之前要评估内存余量不要以为数据量 8GB 就敢把机器压到只剩 2GB 空闲。4.3 相关参数、THP 与优化手段评估 fork 是否拖累业务不能靠感觉。INFO stats里的 latest_fork_usec 能看到最近一次 fork 耗时单位微秒。如果这个值经常在几十毫秒甚至几百毫秒说明 fork 已经明显影响主线程了。再用INFO persistence看 rdb_last_bgsave_status、rdb_bgsave_in_progress、aof_rewrite_in_progress 等状态判断当前是否在后台保存或重写。优化有几个方向。第一保证系统内存充裕避免 fork 时没有足够内存分配页表Linux 上可以设置 vm.overcommit_memory1。第二关注透明大页也就是 THP。Redis 官方建议关闭 THP因为写时复制在 THP 开启时可能因为“按 2MB 大页复制”导致内存放大和延迟飙升可以用echo never /sys/kernel/mm/transparent_hugepage/enabled关闭。第三如果实例数据量太大、写频太高优先做实例拆分别让单个 Redis 背上几十 GB 数据还频繁 bgsave。第四主从架构里让从节点承担备份和持久化任务主节点尽量少做重活。4.4 fork 到底参与了哪些持久化动作顺着这个思路往下走你会发现 fork 其实参与了所有“把当前数据集转成文件”的动作bgsave、bgrewriteaof、主从全量同步时生成 RDB。它们的共同点是都需要处理内存中的全量数据而做到不阻塞单线程主进程的通用方案就是 fork 子进程再让子进程异步写文件。这也是为什么 Redis 日志里出现 Background saving started 时父进程往往只是卡了一下真正耗时的磁盘写入全在子进程里。理解了这套组合拳你就理解了 Redis 持久化为什么这么设计快照文件保存最终状态日志文件保存过程记录fork 提供异步落盘能力。三者合在一起才既快又稳。5. 面对实际场景怎么选型和落地配置5.1 先记住三个维度的对比面对 RDB 和 AOF 的选择很多人纠结。把差异提炼成一张表就好懂了维度RDBAOF恢复速度快直接加载二进制快照慢纯 AOF 要逐条重放命令丢失窗口两次快照之间的数据取决于 appendfsynceverysec 最多丢 1 秒文件形态紧凑二进制快照追加式命令日志会膨胀资源影响fork COW内存可能明显上涨重写期间也有类似影响典型用途全量备份、灾备、迁移高可用、低丢失业务场景所以生产环境里我更推荐“两个都开”RDB 负责全量快照和灾备AOF 负责缩小丢失窗口。它们不是二选一的关系而是互补关系。混合持久化更是把两者的优点捏在了一起。5.2 不同业务怎么选如果你是纯缓存比如商品详情、用户资料、验证码丢了可以回源重建那么默认 RDB 配置就够了甚至极端场景可以关闭持久化前提是能接受重启后缓存全空。如果你是分布式锁、订单状态、幂等记录、活动计数这类数据那必须开 AOF而且 appendfsync 至少要 everysec关键账务操作可以考虑 always但要提前做性能和容量测试。如果你把 Redis 当轻量消息队列或延迟队列用消息丢失会造成业务缺口同样建议 AOF 定期 RDB 双重持久化同时把备份文件放到独立存储。顺带说一句“缓存穿透”和持久化的关系常被人搞混。持久化解决的是重启后缓存空窗的问题但空窗导致大量请求回源数据库时确实会引发类似穿透的雪崩效应。所以对缓存体系来说持久化不只是为了不丢数据也是保护底层数据库的冷启动预案。5.3 一份可直接抄的配置模板以 Redis 6/7 为例给一份兼顾性能与安全的配置参考具体数值按业务调整save 3600 1 save 300 100 save 60 10000 appendonly yes appendfilename appendonly.aof appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-use-rdb-preamble yes dir /data/redis dbfilename dump.rdb这段配置的含义是RDB 按默认节奏做快照AOF 开启并每秒刷盘AOF 超过上次重写体积的 100% 且至少 64MB 时自动重写混合持久化开启数据文件统一放 /data/redis。上线前记得对这个目录做磁盘容量和 IO 监控。云主机上尤其要小心数据目录所在的磁盘被限制了 IOPS不然一个 bgrewriteaof 就可能把磁盘拖垮。6. 常见故障与排查技巧实录6.1 报错Cannot allocate memory后台保存或重写失败日志里出现fork: Cannot allocate memory。很多新手以为真的是机器内存不够其实更多是 Linux 内存 overcommit 策略在作怪。fork 时系统要按子进程的地址空间估算内存需求如果 overcommit 策略禁止超额分配即使物理内存还有富余fork 也会失败。解决办法是修改 vm.overcommit_memory1允许超额分配。修改后重启 Redis通常能恢复。容器环境里还要检查 cgroup 内存限制和 ulimit限制太紧同样会 fork 失败。6.2 日志出现 MISCONF Redis is configured to save RDB snapshots...这条报错通常出现在磁盘空间满了或者数据目录没写权限的时候。Redis 配置了自动 save但后台保存一直失败于是它拒绝继续提供写服务防止你“以为存了其实没存”。排查顺序先df -h看数据目录所在分区的剩余空间再确认运行 Redis 的用户对目录有写权限最后看日志里更早的报错详情。修好磁盘或权限之后确实恢复了不一定等于状态正常手动执行一次 bgsave 让持久化状态复位或者干脆重启实例。6.3 重启加载 AOF 失败Bad file format reading the append only file大概率是宕机时 AOF 尾部写了半条命令或文件被截断。处理步骤先备份损坏文件再用redis-check-aof --fix appendonly.aof修复工具会删除残缺尾部然后重启加载。如果文件头部已经坏了修复工具往往无能为力只能从备份恢复。这件事说明一个道理持久化文件本身也要备份不能只靠 Redis 自己写的那一份尤其是“唯一一份”永远等于“没有备份”。6.4 开启 AOF 后重启恢复慢得离谱恢复慢的根因多数是两个AOF 文件太大或者没开混合持久化。纯 AOF 恢复要逐条重放命令数据量一大比加载 RDB 慢好几倍。建议开启 aof-use-rdb-preamble并配合自动重写控制文件体积。大型节点要缩短停机窗口可以走主从架构做滚动重启先重启从节点确认数据正常再切换流量最后重启原主节点这样业务几乎无感。6.5 大 key 和透明大页两个隐形杀手排查久了会发现持久化问题很多时候不是持久化本身而是底层条件太差。比如大 key。一个包含几百万元素的超大 hash如果在 bgsave 期间被修改COW 会复制这个 key 涉及的大量内存页内存涨幅和耗时都会明显放大。大 key 还会让 RDB 加载变慢、主从同步变慢属于需要主动治理的对象。透明大页的问题前面提过它在 fork 后触发 COW 时会按 2MB 大页复制内存造成内存放大和更高延迟。Redis 官方建议关闭。这行配置在很多部署文档里都有但很多机器实际没做。我建议运维同学把它写进系统初始化脚本别等出问题了再补。6.6 排查工具与监控速查最后把常用命令整理一份INFO persistence看 rdb_last_bgsave_status、rdb_bgsave_in_progress、aof_last_write_status、aof_rewrite_in_progressINFO stats看 latest_fork_usec判断最近一次 fork 耗时BGSAVE / BGREWRITEAOF手动触发后台保存和 AOF 重写redis-check-aof --fix修复受损 AOF 文件redis-check-rdb校验 RDB 文件完整性我实际排查时都是先看 INFO persistence 里的状态位再拉日志找最后一个错误关键字基本能覆盖九成持久化问题。另外有个小习惯值得分享每次改动持久化相关配置之前先把当前持久化文件复制一份到临时目录改动后观察一段时间再删。这个习惯帮我挡过好几次配置手滑导致的灾难。备份永远比修复容易这句话在持久化世界里就是铁律。