第11章 AOF持久化

沿命令追加、缓冲区写入、fsync、载入重放和后台重写理解AOF 覆盖4个正式节点，并以Redis 3.0源码、故障和恢复对账验收。

学习目标

能说明 AOF 的追加与重放原理
能比较三种 fsync 策略的取舍
能解释重写与混合持久化的作用

为什么从“AOF追加与重写双缓冲台”开始

第11章 AOF持久化的核心任务是沿命令追加、缓冲区写入、fsync、载入重放和后台重写理解AOF。命令返回值只暴露外层合同；实现解释还必须连接内存结构、写入与读取路径、事件顺序以及失败后的旧状态回收。AOF追加与重写双缓冲台把这些关系放进同一条可复位轨迹。

先写预测：当fsync策略由“everysec”进入“no”时，哪个可观察状态最先变化？再规定什么结果会推翻当前解释。交互中的分数只表达透明因果方向，不冒充真实Redis测量。

来源、版次与独立重写边界

黄健宏作者读者服务页确认正式出版新版以Redis 3.0为源码基线，列出4部分、24章及完整小节，并链接Redis 3.0中文注释源码。本课程据此映射24个正式单元、145个目录节点，另设学习地图和总复习；未取得出版正文授权，目录只界定范围，不宣称复现原书正文。

本章字段与控制流由Redis官方3.0源码：aof.c和作者注释源码交叉核对；Redis当前持久化文档只用于辨认版本差异。中文解释、图示、交互、实验与答案均为独立教学重写，不把目录页或代码仓库许可证误报为原书许可证。

本章术语与源码合同

第11章 AOF持久化必须守住“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”。观察同时记录AOF追加与重写双缓冲台一致率与重写阶段分叉风险；只有结构快照、函数入口、运行结果和故障反例互相一致，才接受实现结论。

⚡ AOF 持久化

逐条追加写命令

AOF 把每个写命令追加到文件末尾，恢复时重放命令重建数据，比 RDB 丢失窗口小得多。

注入常见故障（高亮各环节的失败模式）

作者目录逐项深读

AOF持久化的实现

四级证据 1/4。 写命令先按协议追加到aof_buf，再由事件循环写文件并按appendfsync策略决定同步时点。本节点用“AOF持久化的实现”作观察点，执行rg 'feedAppendOnlyFile|flushAppendOnlyFile|rewriteAppendOnlyFile' src/aof.c或等价源码探针，保存版本、输入、前后状态和能推翻解释的反例。

验证AOF持久化的实现时，先预测fsync策略从“everysec”切到“no”会改变哪个字段、偏移、文件或消息；再固定重写阶段做一次对照。若故障注入没有破坏“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”，就撤回当前解释而不是补写故事。

AOF文件的载入与数据还原

四级证据 2/4。 载入创建伪客户端顺序重放AOF命令；截断恢复只能在明确配置与协议边界下进行。本节点用“AOF文件的载入与数据还原”作观察点，执行rg 'feedAppendOnlyFile|flushAppendOnlyFile|rewriteAppendOnlyFile' src/aof.c或等价源码探针，保存版本、输入、前后状态和能推翻解释的反例。

验证AOF文件的载入与数据还原时，先预测fsync策略从“everysec”切到“no”会改变哪个字段、偏移、文件或消息；再固定重写阶段做一次对照。若故障注入没有破坏“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”，就撤回当前解释而不是补写故事。

AOF重写

四级证据 3/4。 后台重写从当前数据库状态生成最短等价命令；父进程把期间增量保存到重写缓冲，结束时追加后原子替换。本节点用“AOF重写”作观察点，执行rg 'feedAppendOnlyFile|flushAppendOnlyFile|rewriteAppendOnlyFile' src/aof.c或等价源码探针，保存版本、输入、前后状态和能推翻解释的反例。

验证AOF重写时，先预测fsync策略从“everysec”切到“no”会改变哪个字段、偏移、文件或消息；再固定重写阶段做一次对照。若故障注入没有破坏“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”，就撤回当前解释而不是补写故事。

重点回顾

四级证据 4/4。 第11章 AOF持久化的回顾要重新证明“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”，并用同一输入比较结构前态、变更轨迹、故障首错与恢复后态

验证重点回顾时，先预测fsync策略从“everysec”切到“no”会改变哪个字段、偏移、文件或消息；再固定重写阶段做一次对照。若故障注入没有破坏“确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价”，就撤回当前解释而不是补写故事。

最小源码与运行切片

+git clone --branch 3.0 --depth 1 https://github.com/redis/redis.git redis-3.0
+cd redis-3.0
+rg 'feedAppendOnlyFile|flushAppendOnlyFile|rewriteAppendOnlyFile' src/aof.c

该切片固定Redis 3.0分支、编译器、配置、数据集和命令序列；先保存结构或函数位置，再运行隔离实例。任何持久化损坏、断线、故障转移、大键或高流量实验都必须使用临时数据并规定CPU、内存、磁盘、延迟和停止上限。

unit: rdi-11-aof-persistence
source_file: aof.c
axis_a: "fsync策略"
axis_b: "重写阶段"
fault: "重写期间漏掉父进程新命令，或把everysec误称为零数据损失"
invariant: "确认策略对应明确丢失窗口，AOF语法完整可重放，重写期间增量不丢且结果等价"
replay: same_version_same_input

三个必须主动触发的误区

误区 1

现象 → fsync 设 always 原因 → 每条落盘吞吐骤降 修法 → 用 everysec 平衡安全与性能

误区 2

现象 → AOF 永不重写 原因 → 文件膨胀恢复变慢 修法 → 配置自动重写并观察触发

误区 3

现象 → 重写期间高峰写入 原因 → 缓冲区暴涨风险 修法 → 重写安排低峰并监控缓冲

小结

AOF 追加记录每个写命令
三种 fsync 策略权衡耐久性能
重写压缩冗余命令
混合持久化兼顾加载速度
恢复时 AOF 优先于 RDB

练习、答案与节点验证

练习

问题 1： everysec 策略为什么被推荐？

问题 2： AOF 重写解决什么问题？

问题 3： 估算一个每秒 1000 写的服务一周 AOF 增长量并给出重写策略。（独立实现）

术语复核与本章回顾

完成第11章 AOF持久化意味着能从aof.c解释沿命令追加、缓冲区写入、fsync、载入重放和后台重写理解AOF，能运行章专属状态实验，能制造反例并在复位后证明旧状态没有残留。