Redis 作为缓存来用时很多人容易忽略一个关键点内存里的数据进程一退出就全部归零。可到了真实业务里Redis 里往往不止有“缓存”还有登录会话、排行榜、计数器、分布式锁和异步任务队列。一旦宕机或重启这些数据如果全丢损失往往不是“重新访问一次数据库”能弥补的。这篇文章是 Redis 简单介绍的第三篇重点讲持久化的实现RDB 快照、AOF 日志、混合持久化以及它们背后的运行机制和故障恢复场景。无论你是刚入门还是已经在生产环境跑过一段时间只要关心数据安全这篇都值得认真看。1. 持久化到底在解决什么问题1.1 只把 Redis 当缓存你忽略了什么Redis 之所以快核心原因是把所有数据都放在内存里。内存的读写速度远高于磁盘但同时也有一个天然短板掉电或进程退出后内存内容会全部消失。如果业务只把 Redis 当作“最终一致性的缓存”那丢了还能回源数据库但如果是会话、未写入数据库的计数、临时分布式锁等强状态数据一旦丢失业务会出现难以预测的连锁问题。我见过不少新手在测试环境关掉持久化觉得重启之后 Redis 干干净净反而“方便”。一旦到了生产环境这个习惯就容易出事故。打个比方Redis 就像一个只放内存的操作台操作台上摆满了半成品零件。突然断电零件全没了。持久化要做的就是每隔一段时间把操作台拍照存档或者把每一步手工动作记录到本子上下次重新开门时可以按图恢复。所以持久化不是 Redis 的“可选项”而是数据安全层面的底线。哪怕你认为你的场景全部是缓存也应该至少保留一种持久化手段作为保险。1.2 两条路线全量快照与操作日志Redis 提供了两种核心持久化方式思路完全不同。RDBRedis DataBase走的是全量快照路线。它会选择一个时间点把此刻内存里的所有数据按照二进制格式完整写入一个压缩文件。恢复时直接把这个文件加载回内存速度极快。但问题在于快照之间存在时间窗口窗口内新写入的数据在宕机时可能全部丢失。AOFAppend Only File走的是操作日志路线。它把每次对 Redis 的写命令以追加的方式记录到日志文件里。恢复时重放这些日志命令相当于把写操作重新执行一遍。这样丢失数据的窗口比 RDB 小很多甚至可以做到每命令落盘但日志文件会不断膨胀恢复速度也相对慢。两种方式各有取舍Redis 4.0 之后还推出了兼顾两者的混合持久化。理解这三者是掌握 Redis 持久化实现的关键。下面我把每一类拆开讲。2. RDB 快照全量压缩备份的实现细节2.1 什么时候生成 RDBRDB 的生成可以由自动触发也可以由手动命令触发。自动触发的核心是save配置。看一段典型配置save 900 1 save 300 10 save 60 10000这段配置的意思是如果 900 秒内发生了至少 1 次写操作就触发一次保存如果 300 秒内发生了至少 10 次写操作就触发一次保存如果 60 秒内发生了至少 10000 次写操作也触发一次保存。也就是说只要满足“时间 写入次数”任意一个条件Redis 就会自动生成 RDB 快照。手动生成命令有两条save由当前进程直接写 RDB 文件期间会阻塞所有客户端生产环境绝对不要用。bgsavefork 出一个子进程后台写快照父进程继续服务客户端生产环境常用这种方式。建议在业务低峰期手动执行bgsave或者在配置里把save条件调整得适合业务写入节奏避免高并发时段因为自动快照造成额外负载。2.2 bgsave 背后的 fork 与 Copy-on-Writebgsave之所以能“后台”持久化依赖的是操作系统的 fork 机制。Redis 主进程调用 fork 创建子进程子进程继承主进程的内存页。由于子进程不修改数据它可以快速把内存里的数据页写入临时 RDB 文件。父进程在此期间继续接收写请求。但如果父进程有新的写入情况就变了。操作系统为了保证子进程看到的快照仍是 fork 时间点的状态会使用写时复制Copy-on-Write简称 COW机制父进程要修改某个内存页时会先把这一页拷贝一份给子进程自己在原页上改。这样子进程能拿到完整、一致的历史快照但父进程则会因此产生额外的内存和 CPU 开销。这也是为什么大实例执行bgsave时偶尔会发现内存占用突然升高。如果在 fork 之后出现大量写入COW 触发的内存复制会非常可观。生产环境建议关闭 Linux THP 大页透明机制合理设置maxmemory避免写入量过高导致 fork 期间的毛刺被放大。2.3 RDB 文件长什么样RDB 默认生成在配置的dir目录里文件名为dump.rdb。这个文件是二进制格式不是给人直接读的。它内部会记录数据库版本、数据类型、键值数据、过期时间以及校验信息等相当于整个 Redis 数据库在某一个时间点的完整快照。要查看 RDB 文件是否健康可以使用 Redis 自带的检查工具redis-check-rdb /path/to/dump.rdb这个命令会扫描文件并输出校验结果比如文件里有多少个键、是否有损坏。注意不同版本的工具和 RDB 文件之间可能有兼容性差异升级 Redis 时最好先把旧文件备份好再让实例加载。RDB 文件最大的优点就是紧凑和恢复快。因为它是近乎“原样”的全量内存快照恢复时直接加载即可不需要逐条执行命令。缺点也很明显两次快照之间的数据修改不会在文件里体现一旦在这段窗口内崩溃这中间的所有写入都会丢。2.4 配置与实操检查常见的 RDB 相关配置配置项作用save 禁用 RDB 持久化dbfilename dump.rdb设置 RDB 文件名dir /data/redis设置持久化文件目录stop-writes-on-bgsave-error yesbgsave 失败时是否停止写入第4个配置很关键。默认情况下如果 bgsave 失败Redis 会停止接受新的写请求目的是让运维人员尽快发现备份异常。但有些人为了“不让业务中断”会把这个配置改成 no结果就是备份持续失败但业务还在继续写故障恢复时才发现没有任何可用的快照。我的建议是在监控完备之前保留默认的 yes。实操检查时可以使用info persistence看持久化状态特别关注这几项rdb_last_bgsave_status:ok rdb_changes_since_last_save:42状态为ok说明最近一次 bgsave 成功第二个字段表示上次持久化之后又有多少条写操作能帮你判断当前的数据丢失窗口是否还可以接受。3. AOF 日志每步写入的忠实记录3.1 AOF 开启与三种刷盘策略AOF 的开启方式非常简单appendonly yes appendfilename appendonly.aof开启后Redis 会将每一条写命令追加到 AOF 文件末尾。不过命令是写入了操作系统内核的缓冲区还是真正落到磁盘取决于appendfsync策略。它有三个值always每执行一条写命令都调用fsync强制刷盘。数据安全度最高但性能开销最大写入吞吐会明显下降。everysec每秒刷一次盘。这是默认值也是推荐值宕机最多丢失 1 秒的写命令性能损耗可控。no由操作系统根据自身调度决定何时刷盘性能最好但宕机时可能丢失最近几秒甚至更长时间的数据。我见过有的团队为了提升写入性能把appendfsync设置成no后来遇到一次机器断电丢失了几秒钟的核心数据。选型时要把“允许丢失的窗口”想清楚不要为了省一点性能在数据安全上冒险。3.2 AOF 文件怎么记录命令AOF 文件与 RDB 文件的最大区别是它是文本格式记录的是 Redis 序列化协议RESP写入命令。比如执行SET order:1001 42AOF 里会追加类似这样的内容*3 $3 SET $10 order:1001 $2 42这种格式虽然看起来占空间但它有个好处人可以读懂也能用脚本对特定命令做审查。恢复时Redis 会逐条解析并执行这些写命令相当于把之前的“操作过程”重放一遍。AOF 文件还有一个我比较喜欢的特性它能用来做紧急修复。如果某条业务命令被误执行理论上你可以从 AOF 里找到对应命令并分析影响。虽然不建议人工直接改 AOF 作为常规手段但真到需要复盘时AOF 的存在让问题定位容易得多。3.3 AOF 重写日志无限增长的解药AOF 有一个绕不开的问题文件会越来越大。每次写入都追加长期运行后磁盘占用和恢复耗时都会不可控。比如你执行了 100 次SET来更新同一个键AOF 里会记 100 条命令但实际上只需要最后一条就够了。解决办法是 AOF 重写。重写不是对旧文件做整理而是基于当前内存里的最新数据生成一组能够重建当前状态的最小命令集写入临时文件。例如一个键最终值是 42重写时只保留一条SET命令。重写可以由命令BGREWRITEAOF手动触发也可以自动触发。相关配置auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb意思是当 AOF 文件体积比上一次重写后的基础体积增长超过 100%并且文件大于 64MB 时自动触发重写。重写会 fork 子进程子进程一边生成快照级别的命令集父进程一边把重写期间的新增命令写入缓冲区最终合并到新文件保证数据不丢失。这个机制设计得比较讲究但同样会带来 fork 和磁盘 IO 开销需要在业务低峰或监控容忍范围内处理。3.4 AOF 的优缺点与适用场景AOF 的优势在于数据安全性更好。如果使用everysec最多只丢 1 秒数据使用always理论上不丢数据。AOF 文件可读、可修复也方便复盘写入模式。劣势是文件体积通常远大于 RDB恢复时要重放大量命令导致启动恢复时间比 RDB 慢很多。如果写负载很高AOF 追加本身也会产生额外性能开销。适合使用 AOF 的场景一般是对数据一致性要求比较高的业务比如订单状态、支付流程、积分变动等。不过如果只考虑数据安全我建议不要纠结“用 AOF 还是 RDB”而应该直接上混合持久化。4. 混合持久化Redis 4.0 后的更优解4.1 为什么要把 RDB 放进 AOFRDB 恢复快但丢数据窗口大AOF 丢数据窗口小但恢复慢。很多团队在中间纠结很久其实 Redis 早已给出了第三种答案混合持久化。混合持久化的思路很直接AOF 重写时不再只是生成“最小命令集”而是先生成一份 RDB 格式的全量数据追加到 AOF 文件头部然后再把重写期间的新增命令以 AOF 文本格式追加到尾部。也就是一个文件里既有 RDB 快照又有增量命令日志。恢复时Redis 会先加载文件头部的 RDB 部分把快照瞬间的内存数据直接载入接着解析并执行尾部 AOF 部分的增量命令把数据恢复到最新一致状态。这样既享受了 RDB 的快速加载能力又保留了 AOF 的低丢数据窗口优势。4.2 配置方法与文件结构混合持久化在 Redis 4.0 引入到了 5.0 之后默认开启。确认配置项如下appendonly yes aof-use-rdb-preamble yes注意这个配置生效的前提是 AOF 已经开启。如果你之前用的是纯 AOF想切换成混合持久化修改配置后不会立刻对已有文件生效需要触发一次 AOF 重写让新格式文件生成。可以使用命令BGREWRITEAOF执行完之后AOF 文件头部就会变成二进制 RDB 格式尾部是之后的文本写命令。从文件大小上也能看到明显变化因为 RDB 头部非常紧凑重写后的文件体积会比纯 AOF 小很多。4.3 升级与回滚注意混合持久化虽然好用但有一个兼容性陷阱需要特别注意旧版本 Redis 不一定能识别新格式的 AOF 文件。如果你要回滚到 4.0 之前的版本而文件已经带有 RDB 前缀大概率会加载失败或处理异常。所以升级前至少要做好两件事保留纯 AOF 或 RDB 的备份作为回滚保险。在临时实例里用新版本加载并测试业务核心路径确认没问题再切流量。切换持久化格式这类操作最怕的是“升级一时爽回滚想撞墙”。任何底层格式变化都要当成一次发布操作来对待而不是改个配置就算完。4.4 我的选型建议生产环境里我个人倾向直接使用混合持久化。它把“全量快照”和“增量日志”的优点结合得比较自然。但在混合持久化之外我还会定是保留独立的 RDB 快照用于异地冷备或数据迁移。原因很简单AOF 文件再可靠也挡不住磁盘坏道或者人为误删数据目录。多一份独立格式的 RDB 备份恢复时就更从容。如果你所在团队运维能力有限也可以在从节点上开启持久化主节点只负责读写避免持久化过程与高写入互相争抢资源。这一点我会在第 6 部分展开。5. 故障恢复与数据一致性实战5.1 Redis 启动时的加载优先级Redis 启动恢复数据时会在数据目录中检查持久化文件。加载逻辑可以简化为如果存在 AOF 文件优先加载 AOF否则加载 RDB。这里说的 AOF 文件也包括启用了混合持久化后带 RDB 前缀的 AOF 文件。启动之后可以通过日志确认加载结果。通常会看到类似DB loaded from disk的提示。经验不足的同学容易忽略这一步等到查询业务数据发现不对时再回来看日志反而浪费时间。更稳妥的做法是启动后用客户端连接检查关键总数redis-cli dbsize如果加载的是全量备份dbsize应该与备份时基本一致。如果是主从结构还要确认复制偏移量是否正常避免从节点带着老数据对外服务。5.2 备份文件的验证与迁移我经常跟人强调备份文件不是“只要生成了就一定能用”。磁盘故障、异常写入、版本不兼容都可能导致备份不可用。因此定期做“恢复演练”很有必要。验证 RDB 文件可以使用redis-check-rdb dump.rdb验证 AOF 文件可以使用redis-check-aof appendonly.aof如果发现文件尾部有不完整命令redis-check-aof --fix可以在尽量保留有效数据的前提下修复。修复前一定要先复制原文件因为修复过程会重写文件一旦误操作可能丢更多数据。更彻底的做法是在另一台机器或同一台机器的隔离端口启动临时实例把dir指向备份目录观察能否正常起来再抽查几个业务键。这一步虽然要多花几分钟但能避开“真到恢复时才发现备份损坏”的灾难。5.3 常见数据丢失窗口分析不同持久化配置对应的丢数据窗口差异很大。下面简单梳理持久化配置宕机后最大丢失窗口只开 RDBsave 900 1最多约 15 分钟只开 AOFappendfsync everysec最多约 1 秒只开 AOFappendfsync always基本不丢数据混合持久化AOF 尾部仍用 everysec最多约 1 秒完全关闭持久化内存里所有数据全部丢失这里要注意的是RDB 的丢失窗口不是固定值而是取决于自动快照的触发条件。如果写入不频繁可能实际丢失窗口远大于配置里的时间。所以如果业务接受不了几秒以上的数据丢失就不要依赖纯 RDB。5.4 模拟测试怎么做上线前做一次恢复演练并不复杂。可以准备一个测试实例写入一批模拟 key执行bgsave再继续写入一批新 key然后直接kill -9模拟异常断电。重启后观察哪些 key 还在哪些 key 丢了。这个操作能非常直观地让你理解当前持久化配置到底能保多少数据。我建议每个生产 Redis 实例都保留这样一套演练记录。不要等到真正宕机时才发现自己对恢复流程完全没把握。真实故障现场每一分钟都很贵。6. 高频问题排查与性能调优速查6.1 bgsave 之后请求变慢怎么定位bgsave不像save那样全程阻塞但并不是完全无感。常见卡顿点有两个fork 阶段父进程创建子进程时需要复制进程描述符、页表等结构。实例内存越大fork 耗时越长极端情况下可能造成毫秒级到秒级的停顿。COW 阶段fork 后如果有大量写入父进程要复制被修改的内存页内存占用和 CPU 开销都会上升。排查时先看info stats里的latest_fork_usec如果这个值经常超过几百毫秒说明 fork 开销过大。再结合监控看是否有内存毛刺和磁盘 IO 瓶颈。优化方向包括关闭 THP 透明大页、避免单个实例内存过大、把数据分片到多个实例、把持久化集中到写入量小的从节点上执行。6.2 AOF 文件损坏怎么办AOF 文件最常出现的损坏是尾部截断比如机器断电时文件只写了一半。此时如果配置了aof-load-truncated yes默认值Redis 会自动忽略尾部不完整命令并启动这是最省事的场景。如果文件中间损坏启动时可能直接报错。此时可以使用修复工具redis-check-aof --fix appendonly.aof修复前先备份原文件。修复原理是把文件里无法解析的部分截断丢弃保留前面有效命令。如果 AOF 里恰好有重要业务写入命令在损坏区域那这部分数据就救不回来了。所以光靠单个文件不够记得结合 RDB 快照和异地备份做双保险。6.3 持久化监控指标速查通过info persistence能看到很多关键状态。常用指标如下指标含义关注点rdb_last_bgsave_status最近一次 bgsave 是否成功必须是 okrdb_changes_since_last_save距离上次快照后变化的数据量太大说明备份滞后aof_last_bgrewrite_status最近一次 AOF 重写是否成功必须是 okaof_last_write_statusAOF 每次 fsync 写盘是否成功必须是 okaof_current_sizeAOF 当前文件大小观察增长速度aof_base_size上次 AOF 重写后的基础大小配合计算增长率建议把这些指标接入监控告警。持久化失败不应该等到用户报障才发现而应该在失败的那一刻就触发告警。6.4 运维建议与常见误区最后整理几条比较实用的运维建议。大 key 是持久化的隐形杀手。无论是 RDB fork 写快照还是 AOF 重写大 key 都会放大 COW 开销。建议定期用redis-cli --bigkeys排查并对可疑大键做拆分或清理。持久化文件目录要与 Redis 数据目录本身分开规划。最好使用独立磁盘或云盘避免其他业务的大量 IO 与 Redis 持久化互相影响。多个 Redis 实例共用一份持久化配置时要单独核对dir路径。我见过不止一次实例启动后找不到数据原因是多个实例的dir被配置到了同一个目录相互覆盖了 dump 文件。从节点可以承担持久化任务。如果主节点写入压力大可以关闭主节点的 AOF 自动重写设置从节点持久化再做一次数据校验这样既减少主节点压力又能保住数据。持久化不是锦上添花它是一整套“数据底线机制”。RDB 适合快速恢复AOF 适合低丢失窗口混合持久化则把两者优势结合起来。我自己的实操经验是上线前多花半小时做一次恢复演练比故障后花几小时救数据要值得太多。选型时想清楚你能容忍多少数据丢失再看看磁盘、内存和监控基线技术决策自然就清晰了。