第10章 RDB持久化
比较SAVE与BGSAVE,追踪自动保存条件、RDB文件结构、载入顺序与校验 覆盖5个正式节点,并以Redis 3.0源码、故障和恢复对账验收。
学习目标
- 能比较 SAVE 与 BGSAVE 的差异
- 能解释 fork 与写时复制的一致性保证
- 能评估 RDB 的丢失窗口与适用场景
为什么从“RDB快照恢复台”开始
第10章 RDB持久化的核心任务是比较SAVE与BGSAVE,追踪自动保存条件、RDB文件结构、载入顺序与校验。命令返回值只暴露外层合同;实现解释还必须连接内存结构、写入与读取路径、事件顺序以及失败后的旧状态回收。RDB快照恢复台把这些关系放进同一条可复位轨迹。
先写预测:当保存方式由“BGSAVE”进入“自动保存”时,哪个可观察状态最先变化?再规定什么结果会推翻当前解释。交互中的分数只表达透明因果方向,不冒充真实Redis测量。
来源、版次与独立重写边界
黄健宏作者读者服务页确认正式出版新版以Redis 3.0为源码基线,列出4部分、24章及完整小节,并链接Redis 3.0中文注释源码。本课程据此映射24个正式单元、145个目录节点,另设学习地图和总复习;未取得出版正文授权,目录只界定范围,不宣称复现原书正文。
本章字段与控制流由Redis官方3.0源码:rdb.c和作者注释源码交叉核对;Redis当前持久化文档只用于辨认版本差异。中文解释、图示、交互、实验与答案均为独立教学重写,不把目录页或代码仓库许可证误报为原书许可证。
本章术语与源码合同
第10章 RDB持久化必须守住“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”。观察同时记录RDB快照恢复台一致率与故障时点分叉风险;只有结构快照、函数入口、运行结果和故障反例互相一致,才接受实现结论。
- 1.RDB 持久化:BGSAVE 通过 fork 子进程异步生成快照,SAVE 全程阻塞服务。
作者目录逐项深读
RDB文件的创建与载入
四级证据 1/5。 SAVE在主进程同步写快照,BGSAVE由子进程写临时文件并成功后替换;启动载入要校验类型和尾部。本节点用“RDB文件的创建与载入”作观察点,执行rg 'rdbSave|rdbLoad|rdbSaveBackground' src/rdb.c或等价源码探针,保存版本、输入、前后状态和能推翻解释的反例。
验证RDB文件的创建与载入时,先预测保存方式从“BGSAVE”切到“自动保存”会改变哪个字段、偏移、文件或消息;再固定故障时点做一次对照。若故障注入没有破坏“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,就撤回当前解释而不是补写故事。
自动间隔性保存
四级证据 2/5。 save条件按时间与dirty变更数触发,serverCron检查条件并避免与已有RDB/AOF子进程冲突。本节点用“自动间隔性保存”作观察点,执行rg 'rdbSave|rdbLoad|rdbSaveBackground' src/rdb.c或等价源码探针,保存版本、输入、前后状态和能推翻解释的反例。
验证自动间隔性保存时,先预测保存方式从“BGSAVE”切到“自动保存”会改变哪个字段、偏移、文件或消息;再固定故障时点做一次对照。若故障注入没有破坏“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,就撤回当前解释而不是补写故事。
RDB文件结构
四级证据 3/5。 RDB包含版本头、数据库选择、键值与可选过期时间编码,尾部结束标志与校验共同界定完整文件。本节点用“RDB文件结构”作观察点,执行rg 'rdbSave|rdbLoad|rdbSaveBackground' src/rdb.c或等价源码探针,保存版本、输入、前后状态和能推翻解释的反例。
验证RDB文件结构时,先预测保存方式从“BGSAVE”切到“自动保存”会改变哪个字段、偏移、文件或消息;再固定故障时点做一次对照。若故障注入没有破坏“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,就撤回当前解释而不是补写故事。
分析RDB文件
四级证据 4/5。 字节分析必须使用匹配版本的长度和对象编码,并把解析出的键、值、TTL与真实载入结果对账。本节点用“分析RDB文件”作观察点,执行rg 'rdbSave|rdbLoad|rdbSaveBackground' src/rdb.c或等价源码探针,保存版本、输入、前后状态和能推翻解释的反例。
验证分析RDB文件时,先预测保存方式从“BGSAVE”切到“自动保存”会改变哪个字段、偏移、文件或消息;再固定故障时点做一次对照。若故障注入没有破坏“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,就撤回当前解释而不是补写故事。
重点回顾
四级证据 5/5。 第10章 RDB持久化的回顾要重新证明“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,并用同一输入比较结构前态、变更轨迹、故障首错与恢复后态
验证重点回顾时,先预测保存方式从“BGSAVE”切到“自动保存”会改变哪个字段、偏移、文件或消息;再固定故障时点做一次对照。若故障注入没有破坏“快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账”,就撤回当前解释而不是补写故事。
最小源码与运行切片
+git clone --branch 3.0 --depth 1 https://github.com/redis/redis.git redis-3.0
+cd redis-3.0
+rg 'rdbSave|rdbLoad|rdbSaveBackground' src/rdb.c该切片固定Redis 3.0分支、编译器、配置、数据集和命令序列;先保存结构或函数位置,再运行隔离实例。任何持久化损坏、断线、故障转移、大键或高流量实验都必须使用临时数据并规定CPU、内存、磁盘、延迟和停止上限。
unit: rdi-10-rdb-persistence
source_file: rdb.c
axis_a: "保存方式"
axis_b: "故障时点"
fault: "看到dump.rdb存在就宣称可恢复,忽略校验、快照时点和写时复制成本"
invariant: "快照表示一致时点,文件头尾与对象编码可校验,恢复结果与快照时刻对账"
replay: same_version_same_input三个必须主动触发的误区
误区 1
现象 → 生产用 SAVE 备份 原因 → 全程阻塞服务中断 修法 → 只用 BGSAVE 并选低峰执行
误区 2
现象 → 大实例频繁 fork 原因 → 写时复制内存翻倍 修法 → 控制实例大小,错峰生成快照
误区 3
现象 → 只依赖 RDB 容灾 原因 → 间隔内数据全丢 修法 → 叠加 AOF 缩小丢失窗口
小结
- RDB 按时间点生成紧凑快照
- SAVE 阻塞,BGSAVE 派生子进程
- 写时复制保证快照一致性
- 适合备份与灾难恢复
- 间隔内的数据可能丢失
练习、答案与节点验证
练习
问题 1: BGSAVE 为什么可能让内存翻倍?
问题 2: RDB 与 AOF 的丢失窗口有何不同?
问题 3: 为 8GB 实例设计 RDB 备份计划。(独立实现)
术语复核与本章回顾
完成第10章 RDB持久化意味着能从rdb.c解释比较SAVE与BGSAVE,追踪自动保存条件、RDB文件结构、载入顺序与校验,能运行章专属状态实验,能制造反例并在复位后证明旧状态没有残留。