Redis 的持久化这块内容我前前后后翻过不少次车也踩过不少坑。最早接触的时候觉得 RDB 和 AOF 不就是两个配置项嘛开一个就完事了结果线上真出问题的时候才发现光知道“开哪个”远远不够——RDB 到底什么时候触发、AOF 的协议长什么样、重写是怎么个重写法、混合持久化到底是谁写谁读这些细节不清楚排查问题基本靠猜。这篇就把 RDB 手动保存、AOF 协议解读与操作配置、手动重写以及混合持久化这套组合拳按我自己的理解顺序完整捋一遍尽量把每个“为什么这么设计”讲透适合已经用过 Redis 但想把这部分彻底搞明白的朋友也适合刚上手、想少走弯路的新手对照着看。1. 持久化整体设计与选型思路拆解1.1 为什么 Redis 需要两套持久化机制先把最根本的问题说清楚Redis 是内存数据库数据放在内存里进程一挂、机器一断电内存里的东西就没了。持久化的本质就是把内存里的数据以某种形式落到磁盘上下次启动再读回来。听起来简单但“怎么落”这件事有两种截然不同的哲学。一种是快照式某一时刻把整个数据集拍一张照片存下来这就是 RDB。它的思路是“我不管你中间怎么变我只看某个瞬间的全量状态”。另一种是日志式把每一条会修改数据的命令按顺序记下来重放就能还原这就是 AOF。它的思路是“我记录你做的每一件事按顺序再做一遍”。这两种哲学没有绝对优劣只有场景适配。RDB 快照紧凑、恢复快但两次快照之间的数据会丢AOF 记录细、丢得少但文件大、恢复慢。Redis 同时提供两者本质上是让用户根据“能容忍丢多少数据”和“恢复速度要求多高”来做权衡。理解了这个底层分歧后面所有的配置项、重写机制、混合方案都是在这个分歧上做工程折中。1.2 RDB 与 AOF 的核心差异对照在动手配置之前先把两者的关键维度摆在一起看心里有个谱。下面这张表是我自己整理时常看的版本参数都是 Redis 常见默认值附近的量级具体以实际版本为准维度RDBAOF存储内容某一时刻的全量数据快照所有写命令的追加日志文件体积小二进制压缩大文本协议累积恢复速度快直接加载慢逐条重放数据丢失窗口两次快照之间取决于刷盘策略可做到秒级甚至更小对主进程影响fork 子进程写时复制追加写刷盘策略影响性能可读性二进制不可直接读文本协议可读可分析典型用途备份、灾难恢复、主从全量同步对数据安全性要求高的场景这张表里最容易被忽略的是“对主进程影响”那一行。很多人只盯着“丢不丢数据”却忽略了 fork 和写时复制Copy-On-Write在大数据集下可能带来的内存翻倍和延迟抖动这个后面会展开讲。1.3 混合持久化要解决的核心矛盾单独用 RDB恢复快但丢得多单独用 AOF丢得少但恢复慢、文件大。混合持久化就是想把两者的优点拼起来用 RDB 的形式存全量基底用 AOF 的形式存增量命令。这样恢复时先加载 RDB 基底快再重放增量 AOF少既快又丢得少。这里有个特别容易搞混的点标题里写得很清楚——“rdb 恢复aof 接收都写入 aof”。意思是混合持久化开启后AOF 重写时生成的新文件前半段是 RDB 格式的全量数据后半段是 AOF 格式的增量命令而运行期间所有新来的写命令依然全部追加进 AOF 文件。也就是说RDB 只在重写那一刻作为“基底”出现日常接收写入的通道始终是 AOF。这个理解如果错了后面排查“为什么数据没进 RDB”就会完全跑偏。2. RDB 手动保存的核心细节与实操要点2.1 RDB 文件里到底存了什么RDB 是一个二进制文件结构上大致是一个固定的魔数头标识这是 RDB 文件及版本、若干数据库段每个 db 编号下的一批键值对、以及文件尾的校验和。每个键值对会记录键名、值、过期时间如果有、数据类型编码等信息。因为值是按 Redis 内部编码直接序列化的所以体积小、加载快但也意味着你没法用文本编辑器直接看懂。我一般把 RDB 理解成“游戏存档”它不是录像是某个时刻的完整状态快照。你读档进去就是那个时刻的样子中间发生过什么它不关心。这也解释了为什么 RDB 恢复后两次快照之间的写入会丢——因为那些写入根本没被“拍”进去。2.2 手动执行 SAVE 与 BGSAVE 的区别手动触发 RDB 有两个命令区别非常关键SAVE在主线程里同步执行执行期间整个 Redis 阻塞不处理任何其他命令。数据量小的时候感觉不到数据量大时可能卡住几秒甚至更久生产环境基本不能用。BGSAVEfork 一个子进程由子进程去写 RDB 文件主进程继续处理请求。这是生产环境唯一能接受的手动方式。# 同步保存会阻塞主线程仅建议在明确无流量时使用 127.0.0.1:6379 SAVE OK # 异步保存fork 子进程执行生产环境首选 127.0.0.1:6379 BGSAVE Background saving startedBGSAVE返回Background saving started只代表子进程起来了不代表写完了。想看进度和结果用LASTSAVE拿最后一次成功保存的时间戳或者看INFO persistence里的rdb_bgsave_in_progress、rdb_last_bgsave_status等字段。2.3 fork 与写时复制BGSAVE 的性能真相BGSAVE之所以能“不阻塞”靠的是操作系统的 fork 写时复制。fork 的瞬间子进程和父进程共享同一份物理内存页只有当父进程或子进程要修改某个页时才复制一份出来。所以子进程看到的是 fork 那一刻的“冻结视图”能安心把快照写出去。但这里有个坑如果 fork 之后主进程写入非常频繁大量内存页被复制实际内存占用可能接近翻倍。我见过一个实例数据量 8GB 左右BGSAVE 期间内存峰值冲到接近 15GB直接把机器撑到 swap延迟飙升。所以规划内存时不能只按数据量算要预留出 fork 期间写时复制的余量。经验上写入越频繁、数据集越大这个余量要留得越足。注意BGSAVE执行期间如果再收到BGSAVE会被拒绝返回错误但SAVE和BGSAVE之间、以及自动触发和手动触发之间也存在互斥关系配置自动保存规则时要意识到这一点避免手动和自动撞车。2.4 手动保存的典型使用场景手动BGSAVE我主要在几个场景用一是发版或做危险操作前手动打一个快照相当于给自己留个后悔药二是迁移或备份前主动生成一份最新的 RDB方便拷贝走三是排查问题时想固定一个现场。自动保存规则save配置适合日常兜底但关键时刻手动来一发更可控。需要提醒的是手动BGSAVE生成的 RDB 会覆盖dbfilename指定的文件默认dump.rdb如果你想要多个历史快照得自己把文件拷走改名Redis 本身不做多版本管理。3. AOF 协议解读与操作配置3.1 AOF 文件长什么样协议逐行拆解AOF 文件本质是文本协议的命令序列用的是 Redis 自己的 RESP 协议格式。每条命令按“数组 批量字符串”的方式编码读起来不算直观但拆开看很有规律。举个写入SET name redis的例子文件里大致是这样*3 $3 SET $4 name $5 redis逐行解释*3表示这是一个包含 3 个元素的数组即命令有 3 个部分命令名 两个参数$3表示接下来是一个长度为 3 的批量字符串即SET$4表示长度 4 的字符串name$5表示长度 5 的字符串redis。所以整个文件就是一条条这样的“长度前缀 内容”拼起来的。为什么用这种格式而不是直接写SET name redis因为长度前缀让解析器不需要逐字符扫描找分隔符能快速定位每条命令的边界重放时效率更高也不怕值里本身含有空格或特殊字符。这是典型的“用一点冗余换解析确定性”的设计。3.2 三种刷盘策略appendfsync 的取舍AOF 把命令写进文件缓冲区后什么时候真正刷到磁盘由appendfsync控制三个取值always每条命令都刷盘。最安全几乎不丢但每条写都要等磁盘性能最差。everysec每秒刷一次。折中方案最多丢约 1 秒数据性能可接受是绝大多数场景的默认推荐。no交给操作系统决定何时刷。性能最好但丢多少不可控宕机可能丢一大段。# redis.conf 中 AOF 相关核心配置 appendonly yes appendfilename appendonly.aof appendfsync everysec我自己的选择逻辑很简单能接受丢 1 秒就用 everysec不能接受再考虑 alwaysno 基本不用。always在高写入场景下对吞吐的打击是实打实的除非业务对每条写入都极度敏感否则没必要。3.3 AOF 重写为什么文件会越来越大AOF 记录的是“每一条写命令”问题在于很多命令是冗余的。比如你对同一个键INCR了一万次AOF 里就有一万条INCR但最终状态其实只是一个数字。文件越滚越大恢复时重放一万条命令也慢。AOF 重写就是根据当前内存里的实际数据重新生成一份“最小命令集”把冗余历史压掉。重写不是读旧 AOF 来压缩而是直接读当前内存数据反向生成能重建这份数据的最少命令。比如一个 list 里有一万个元素重写后可能就变成一条RPUSH带上万个参数实际会分块而不是一万条RPUSH。这就是为什么重写后的文件能小很多。3.4 手动触发重写与后台重写的机制手动重写用BGREWRITEAOF127.0.0.1:6379 BGREWRITEAOF Background append only file rewriting started它同样是 fork 子进程来做主进程继续服务。但有个关键细节重写期间新来的写命令怎么办Redis 的做法是子进程重写的同时主进程把新命令同时写入旧的 AOF 缓冲区和一个专门的重写缓冲区。子进程写完后主进程把重写缓冲区里的增量追加到新文件末尾再用新文件原子替换旧文件。这样新旧数据都不丢切换也是原子的。自动重写由两个参数控制# 当前 AOF 文件比上次重写后增长了 100% 且不小于 64MB 时触发 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb这两个条件是“且”的关系避免文件很小的时候频繁重写。调这两个参数要结合写入量写得太猛的话可以适当调低百分比让它更早重写但重写本身也耗资源别调得太激进。3.5 AOF 配置的实操落地清单把 AOF 从关到开、从开到调优我一般按这个顺序走确认appendonly yes指定appendfilename和appenddirname新版本支持独立目录。设定appendfsync everysec作为起点。配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size按数据增长节奏调。关注no-appendfsync-on-rewrite重写期间是否暂停刷盘。设为yes能减少重写时的磁盘压力但重写期间宕机可能丢更多需要权衡。上线后盯INFO persistence里的aof_current_size、aof_base_size、aof_rewrite_in_progress等指标。注意开启 AOF 后Redis 启动时会优先加载 AOF如果存在而不是 RDB因为 AOF 通常更完整。这个优先级顺序要记牢否则会出现“我明明有 RDB 为什么加载的是 AOF”的困惑。4. 混合持久化的机制与实操验证4.1 混合持久化到底怎么“混”开启混合持久化aof-use-rdb-preamble yes新版本默认开启后AOF 重写生成的新文件结构变成前半段是 RDB 格式的全量数据后半段是 AOF 格式的增量命令。文件开头会有标识区分这是混合格式。恢复时的流程是先识别前半段 RDB快速加载全量基底再读后半段 AOF重放重写之后产生的增量。这样既享受了 RDB 的加载速度又保留了 AOF 的增量完整性。再强调一遍标题里那个关键点运行期间所有新写入依然全部进 AOF 文件RDB 部分只在重写那一刻作为基底生成。所以不存在“新数据写进 RDB”这回事RDB 在混合模式下是“静态基底”AOF 才是“动态接收通道”。4.2 开启混合持久化后的文件结构验证想亲眼确认结构可以在开启混合持久化后手动触发一次重写然后看文件头# 触发重写 127.0.0.1:6379 BGREWRITEAOF # 查看 AOF 文件头部混合模式下开头应是 RDB 魔数 REDIS head -c 16 appendonly.aof | xxd如果开头能看到REDIS字样RDB 魔数说明前半段确实是 RDB 格式往后翻能看到*开头的 RESP 命令说明后半段是 AOF 增量。这个验证方法我每次换环境都会做一遍确认配置真的生效而不是想当然。4.3 混合模式下的恢复流程与注意事项恢复时 Redis 会自动识别混合格式先加载 RDB 段再重放 AOF 段用户无需干预。但有几个点要注意旧版本兼容性混合格式是较新版本引入的如果降级到不支持的老版本可能读不了新文件。做版本回退前要先确认。文件损坏处理如果 AOF 尾部有半条命令比如写到一半宕机可以用aof-load-truncated yes让 Redis 加载时自动截断尾部不完整部分避免启动失败。备份策略混合模式下 AOF 文件同时含 RDB 和 AOF 两段备份时整体拷走即可不要试图只取其中一段。4.4 RDB、AOF、混合三者的选型建议到底选哪个我给一个自己的判断框架场景推荐方案理由纯缓存丢了能回源只开 RDB简单、恢复快丢数据无所谓数据较重要能容忍秒级丢失AOF everysec平衡安全与性能既要快恢复又要少丢混合持久化兼顾两者优点极高安全要求AOF always 定期 RDB 备份双保险实际生产里我见得最多的是混合持久化 everysec恢复快、丢得少运维负担也小。纯 RDB 多见于缓存场景纯 AOF 现在相对少了因为混合模式基本覆盖了它的优势。5. 常见问题与排查技巧实录5.1 持久化相关高频问题速查表现象可能原因排查方向BGSAVE 报错无法执行已有子进程在跑 / 磁盘满 / fork 失败看INFO persistence、磁盘空间、内存余量重启后数据比预期少加载了 RDB 而非 AOF或 AOF 尾部截断确认加载来源、检查aof-load-truncatedAOF 文件异常膨胀重写未触发或参数不合理看aof_current_size与aof_base_size比值重写期间延迟飙升fork 写时复制 刷盘压力叠加调no-appendfsync-on-rewrite、错峰重写启动报 AOF 格式错误文件损坏或尾部不完整用redis-check-aof检查修复5.2 fork 失败与内存不足的排查思路BGSAVE或BGREWRITEAOF失败最常见的原因是 fork 失败本质是内存不够或进程数限制。排查顺序先看INFO persistence里rdb_last_bgsave_status和aof_last_bgrewrite_status是不是err再看系统日志有没有 fork 相关报错然后确认vm.overcommit_memory设置很多环境需要设为 1 才允许 fork 时超额分配最后看内存余量是否够写时复制。我踩过最典型的一次坑是数据量不大但机器内存被其他进程占满fork 时申请不到页表空间直接失败表现就是“BGSAVE 一直不成功但也没明显报错”。后来把vm.overcommit_memory调成 1 并清理了内存才恢复。这个参数不是 Redis 自己的是操作系统的容易被忽略。5.3 AOF 损坏的修复实操AOF 尾部损坏比如写到一半断电导致启动失败时先用工具检查redis-check-aof appendonly.aof它会报告文件是否完整、在哪一行截断。确认后可以加--fix参数修复它会截掉尾部不完整的命令redis-check-aof --fix appendonly.aof修复前务必备份原文件因为--fix是破坏性操作。修完再启动通常就能正常加载了。如果损坏在文件中间而不是尾部修复工具也救不回来只能靠备份。5.4 我踩过的几个真实坑与经验第一个坑是误以为开了 AOF 就不会丢数据。实际上everysec下最多丢约 1 秒而且如果刷盘线程卡住丢的可能更多。有次磁盘 IO 打满AOF 刷盘延迟正好赶上进程重启丢了将近两秒的写入。从那以后我对“最多丢 1 秒”这个说法都留了余量理解。第二个坑是重写和 BGSAVE 撞车。自动重写和自动 BGSAVE 如果同时触发fork 两个子进程内存和 IO 压力叠加延迟直接起飞。后来我把两者的触发条件错开并监控rdb_bgsave_in_progress和aof_rewrite_in_progress避免同时进行。第三个坑是混合持久化下误判加载来源。有次重启后发现数据比预期旧一度以为 RDB 覆盖了 AOF后来查清楚是 AOF 尾部有截断、加载时截掉了最后一段增量而那段增量恰好包含最近的写入。教训是混合模式下要特别关注 AOF 尾部的完整性aof-load-truncated虽然能避免启动失败但截断本身意味着丢数据得配合监控告警。5.5 监控指标与日常巡检建议持久化这块我日常盯这几个指标rdb_last_bgsave_status最近一次 BGSAVE 是否成功、aof_last_bgrewrite_status最近一次重写是否成功、aof_current_size与aof_base_size的比值判断是否需要重写、latest_fork_usecfork 耗时突然变大说明内存压力上来了、以及rdb_changes_since_last_save距上次保存积累了多少变更。把这些做成定时采集和阈值告警比出事后再翻日志高效得多。尤其是latest_fork_usec它是内存压力和写时复制开销的先行指标涨得离谱的时候往往还没出问题但已经在预警了。最后分享一个我自己的小习惯每次调整持久化相关配置后不只看配置生效没还会手动触发一次 BGSAVE 和一次 BGREWRITEAOF然后重启一次验证加载来源和恢复结果。配置对不对重启一次最清楚比盯着配置文件猜靠谱得多。这套流程走下来持久化这块基本就不会再给你“惊喜”了。