Redis AOF持久化机制深度解析：从原理到故障恢复实践

1. 为什么每个Redis使用者都该搞懂AOF

先说个真实场景。前几年我接手过一个电商项目的缓存服务，当时Redis里存着几万个商品的库存和秒杀活动的状态。某天凌晨机房一台物理机突然断电，等机器重新起来，Redis里原本的数据丢了一大半——因为当时部署的实例只开了默认的RDB快照，而RDB的保存周期是900秒起步，最后十几分钟的数据全没了。库存数据错乱带来的后果，就是早上顾客看到的可购买数量跟仓库对不上，客服电话被打爆。

那之后我就把Redis持久化这件事从头到尾啃了一遍。Redis有两种持久化手段，一种是RDB快照，另一种就是今天要聊的AOF，全称Append Only File，中文通常叫追加写文件。简单理解，RDB是定期给数据拍一张照片，而AOF是把每一次写操作都记成一笔流水账。如果你丢不起数据，AOF基本是绕不开的方案。

这篇文章适合谁看？后端开发、运维、还在准备面试的同学，只要你负责维护的Redis里存着不能随便丢的业务数据，那AOF的机制就值得你彻底搞明白。不仅是配置几行参数那么简单，我会把AOF从写入、刷盘、重写、恢复到故障排查的完整链路都拆开讲，看完你至少能回答清楚三个问题：AOF到底怎么工作的、为什么它能减少丢数据、以及什么时候该用RDB、什么时候该用AOF。

2. AOF的核心设计思路：用日志换数据安全

2.1 Redis为什么不能只靠内存

Redis以速度著称，它的性能奥秘在于所有数据都驻留在内存里，读写不碰磁盘。但这也带来了一个致命问题：内存是易失的。进程退出、系统崩溃、断电，内存中的数据说没就没。一台没有持久化的Redis，本质上就是个带缓存功能的临时存储，重启即归零。

这时候就需要把内存中的数据想办法落盘。RDB的方式是周期性把全量数据序列化后写入磁盘文件，它的优点是恢复快、文件紧凑，缺点是两次快照之间的数据一定会丢。而AOF的思路完全不同：既然每次写操作是让数据状态发生变化的源头，那我把每次写命令都记录下来，重启的时候把这些命令重新执行一遍，数据不就回来了吗？

这个思路等价于记账。RDB相当于隔一段时间拍一次你的资产总览，AOF则是每笔收支都记在账本上。账本记到哪，你的资产状态就能恢复到哪。理解了这一层，AOF存在的意义就清楚了：它在吞吐量和数据安全性之间，给了你一个可以精细调节的选项。

2.2 AOF沿革：从1.0到7.0的演进脉络

AOF不是Redis一诞生就有的，它是在Redis 1.1版本引入的。早期的AOF逻辑非常简单：每执行一条写命令，就把它追加到日志文件末尾。后来随着版本迭代，AOF机制经历了几个重要的节点：

• Redis 2.4版本引入了AOF重写的初步实现，后来在2.6版本里，重写逻辑被调整为基于子进程的方式，也就是今天大家熟悉的BGREWRITEAOF。
• Redis 4.0引入了一个非常重要的特性：混合持久化。开启后，AOF重写生成的日志文件头部是RDB格式的全量数据，后面才是增量命令日志，兼顾了恢复速度和文件体积。
• Redis 7.0又把AOF文件拆成了基础文件和增量文件两部分来管理，解决了以前单个日志文件过大、重写时磁盘占用翻倍的问题。

所以如果你在网上搜到一些Redis 3.x、4.x时代的文章，里面的AOF描述在今天有一部分已经不准确了。尤其Redis 7.0之后，AOF的文件结构、重写机制都有了质的变化，这也是我建议你搞懂原理时一定要确认Redis具体版本的原因。

提示：本篇文章的机制讲解以Redis 7.0及以后版本为主，涉及差异处会额外说明旧版行为。

3. AOF写入链路逐层拆解：一条命令是怎么变成日志的

3.1 从命令执行到写入缓冲区的完整过程

当客户端发来一条写命令，比如SET stock:1001 50，Redis并不是直接把这行文本扔进文件。整个AOF写入路径可以分成四个环节：

1. 命令执行：Redis服务器先执行这条命令，把内存中的数据真正改掉。
2. 协议序列化：命令会被转换成Redis自己的网络协议格式（RESP），说白了就是把命令、参数、参数个数等按特定规则编码成一串文本。
3. 追加到缓冲区：序列化后的内容先写入内存中的aof_buf缓冲区，这个缓冲区是每个Redis服务器进程维护的一块内存区域。
4. 刷盘（flush）：根据配置的策略，在一定时机把aof_buf里的数据写入操作系统内核的页缓存（page cache），再调用fsync把页缓存的数据真正写入磁盘。

这里最关键也最容易被忽略的是第3步和第4步的区别。你调用write()把数据写入文件，这个动作只代表数据交给了操作系统，操作系统并不会立刻把它写到磁盘的物理扇区上，而是先放进内核的页缓存里。什么时候落盘，取决于操作系统自己的调度策略。如果这个节骨眼上机器断电了，页缓存里那部分数据仍然会丢。

所以AOF刷盘策略里讨论的核心，其实是在哪里、以什么频率调用fsync，让数据从内核态真正刷到磁盘。

3.2 三种刷盘策略的取舍：always、everysec、no

Redis的appendfsync配置项控制的就是刷盘时机，它有三个可选值，含义和代价完全不同，我用一个例子来说明差异。

假设当前有10条写命令已经执行完毕，aof_buf里存着这10条命令的序列化结果。

• always：每条命令执行完，立刻把aof_buf内容同步刷到磁盘。数据安全性最高，最多只丢正在执行的那一条命令（严格说，命令执行成功但fsync失败的情形除外）。代价是每次写操作都要等待一次磁盘I/O，吞吐量骤降。实测在这种模式下，Redis的写QPS可能只有默认模式的三分之一甚至更低，所以它只适合对数据安全极端敏感、且写并发极低的场景。
• everysec：aof_buf会先写入系统页缓存，由一个后台线程每隔1秒调用fsync把数据刷到磁盘。这种策略在性能和数据安全之间取了一个平衡。如果机器只是进程崩溃，那页缓存里的数据还在，最多丢失1秒的写入；如果是整机断电，则最多丢失约1秒的数据。
• no：Redis只负责把数据交给操作系统，完全不主动调用fsync，刷新时机完全由操作系统决定（通常是积攒到一定数量或30秒左右刷一次）。这种模式性能最高，但丢数据的风险也最大。操作系统没来得及刷入磁盘的数据，在断电时全都会丢。

我自己线上常用的配置是appendfsync everysec。理由很简单：绝大多数业务能接受最多丢1秒的缓存数据，但接受不了Redis写性能出现断崖式下跌。如果你在金融类、强一致场景，可以在确认写入并发上限后考虑always，但前提是量级足够小。

3.3 配置文件里AOF相关的完整参数清单

AOF相关的配置项不止appendfsync一个，很多人配置AOF失败就是因为只改了一两个参数。一份最基础但完整的AOF配置大概长这样：

# 开启AOF持久化 appendonly yes # AOF文件名的前缀，7.0开始一个实例会生成多个AOF相关文件 appendfilename "appendonly.aof" # 刷盘策略：always / everysec / no appendfsync everysec # 自动触发AOF重写的条件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 当AOF文件尾部不完整时，加载阶段如何处理 aof-load-truncated yes # 开启混合持久化 aof-use-rdb-preamble yes

这里面appendonly yes是总开关，appendfsync everysec是策略选择，auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb控制自动重写的触发条件，aof-load-truncated yes决定启动时遇到文件被截断是自动修复还是报错，aof-use-rdb-preamble yes则是开启混合持久化功能。

很多人在测试环境开启了appendonly yes，结果重启后数据没恢复，检查了半天发现写入的命令确实执行了，但AOF文件没有变大。这时候要确认Redis进程是否有权限在配置的working directory（通常是dir参数指定的目录）里创建文件，以及是不是旧版本中同时开了RDB并且加载顺序导致看起来像是没恢复。

4. AOF重写机制详解：日志不能无限膨胀

4.1 为什么需要重写：一个日志文件能涨到多大

AOF的追加写模式决定了，同一份数据被反复修改多少次，它就会记录多少条命令。举个极端例子：你启动了一个计数器，循环执行10万次INCR counter，AOF文件里就会追加10万条INCR counter命令。但实际上，这10万条历史命令对最终结果只有一个贡献：counter的值加了10万。启动时把这10万条一条条回放，效率极低，文件体积也臃肿不堪。

所以AOF必须有一个机制来压缩日志体积，抹掉那些“中间过程”，只保留最后的结果。这个机制就是重写。重写得到的并不是对原AOF的修修补补，而是基于当前内存中的数据快照，生成一组能够重建当前数据集的最小命令集，然后写到一个临时文件里，最后替换掉旧文件。这样计数器案例中10万条INCR命令就被压缩成了一条SET命令。

4.2 重写触发时机与自动重写的判定逻辑

重写有两种触发方式：手动和自动。手动触发很简单，在redis-cli里执行：

BGREWRITEAOF

这条命令会让Redis在后台异步执行重写，不会阻塞主服务。自动触发则是由配置的两个参数联合控制：

• auto-aof-rewrite-percentage：AOF文件当前体积相比上一次重写后的基准体积的增长比例。默认100，表示当文件增长了一倍时会触发。
• auto-aof-rewrite-min-size：触发重写的最小文件体积。默认64mb，也就是说就算增长率达到了100%，但文件还没有超过64MB，也不会触发。

举个例子：上次重写完成后，AOF文件基准大小为100MB。当文件体积增长到超过200MB时，因为有auto-aof-rewrite-percentage 100，Redis就会在合适时机触发自动重写。如果基准体积很小，比如只有10MB，那即使翻倍到20MB，也还低于64MB阈值，仍然不会触发。这个双重条件的意义在于，防止小体积文件频繁触发无谓的重写，浪费系统资源。

4.3 重写期间读写不冲突的秘密：fork和写时复制

如果你之前觉得AOF重写就是把数据导出再导入一遍，那一定会有个疑问：重写期间新的写命令继续进入Redis，这些数据怎么办？万一重写过程中修改了正在扫描的数据，导出的快照岂不是不一致？

这就要归功于操作系统的写时复制机制。Redis触发重写时，主进程会fork出一个子进程。fork出来的子进程会复制父进程的内存页表，但物理内存是共享的。子进程开始遍历这份共享的内存快照，把数据转换成新的命令写入临时文件。此时如果主进程收到了新的写命令，它只会修改自己的内存页；一旦某个内存页被修改，操作系统就会为这个页做一次复制，让父子进程各自持有独立的副本。子进程始终看的是fork那一刻的数据快照，不受后续写入的影响。

那么问题来了：fork之后的增量写命令怎么处理？答案是它们仍然会正常追加到旧的AOF文件中。重写期间，主进程的aof_buf依旧按正常逻辑写旧文件，同时这批命令也会被额外写入一份重写缓冲区（aof_rewrite_buf_blocks）。当子进程完成全量快照写出后，会通知主进程；主进程再把重写缓冲区中积压的命令补写到临时文件尾部，确保临时文件包含了从fork时刻到重写完成期间的所有数据变更。最后，主进程用rename原子性地把临时文件替换成正式AOF文件，整个重写过程才算落幕。

4.4 手动重写的正确姿势与验证要点

手动触发重写后，怎么确认它真的成功了？最直接的方式是看AOF文件的大小和结构变化。以Linux环境为例，先确认Redis的AOF目录，然后观察文件列表：

# 进入dir参数配置的目录 cd /var/lib/redis # 触发重写 redis-cli BGREWRITEAOF # 观察目录下的文件变化 ls -lh appendonly.aof*

在Redis 7.0之前，你看到的可能只是一个孤零零的appendonly.aof。而在7.0之后，一份完整的AOF数据被拆成了多个文件：一个manifest清单文件（比如appendonly.aof.manifest）、一个或多个基础文件（base文件），以及若干个增量文件（incr文件）。重写完成后，旧的incr文件会被清理，新的base文件会生成。

注意：手动重写命令在Redis 7.0之前写作BGREWRITEAOF，7.0之后仍然兼容这个命令，但Redis官方也建议直接用它。不要用REWRITEAOF，那是阻塞式重写，生产环境不推荐使用。

5. AOF数据恢复流程：文件是怎么变成内存数据的

5.1 启动加载顺序与AOF在其中的角色

很多人以为Redis启动后是先加载RDB再加载AOF，或者两者都加载，这其实是误解。Redis的加载规则是：如果开启了AOF（appendonly yes），启动时优先加载AOF；如果AOF没开启，才尝试加载RDB。绝大多数情况下，二者是互斥的，不会在同一份数据目录中同时加载两套数据。

Redis官方这样设计的原因很简单：AOF记录的数据更新、更完整。如果AOF和RDB同时存在，却优先加载RDB，那相当于用旧数据覆盖新数据。所以在开启AOF的实例中，RDB文件更多扮演的是“AOF缺失时的兜底”角色，而不是日常恢复的主力。

整个启动加载流程大致如下：

1. 检查appendonly配置项。如果为yes，则进入AOF加载流程。
2. 读取manifest清单文件，确认该实例关联了哪些base文件和incr文件。
3. 按顺序加载base文件，如果有混合持久化前缀，则按RDB格式解析恢复；再逐个加载incr文件，重放增量命令。
4. 所有命令重放完成后，数据集构建完毕，Redis开始接收外部请求。

如果你同时开了RDB，又不想让AOF启动加载，那只能在配置里关掉appendonly。不存在“两个都按顺序加载”的情况，很多面试题里问“如果RDB和AOF都开启了，Redis启动时会加载哪个”，正确答案就是：加载AOF。

5.2 AOF文件实际长什么样：手把手看一段日志内容

纸上谈兵不如亲眼看一下。用一个最简单的方式制造一份AOF文件，然后打开看它的内部结构。

首先启动一个只开AOF的Redis实例，执行几条命令：

redis-cli SET city "Beijing" redis-cli INCR visit_count redis-cli INCR visit_count redis-cli HSET user:1001 name "Tom" age 28

然后执行BGREWRITEAOF，再找到AOF文件，用文本方式打开（如果开启了混合持久化，base文件是二进制RDB格式，看不了明文；可以先临时把aof-use-rdb-preamble设为no再测试）。你会看到类似下面的内容：

*2 $6 SELECT $1 0 *3 $3 SET $4 city $7 Beijing *3 $3 SET $6 visit_count $6 6 *4 $4 HSET $8 user:1001 $4 name $3 Tom $2 age $2 28

每一行*N表示后面跟着N个参数，$M表示接下来的内容长度是M字节，后面是具体的内容。SELECT 0用于切换到正确的逻辑数据库，SET、HSET这类命令就是最原始的写命令。重写之后，两条INCR被合并成了一条SET visit_count 6，因为此时计数器的最终值就是6。这就是AOF文本化、可读的一面——当然实际生产环境的AOF通常开启了混合持久化，base部分是不可读的二进制，但incr部分仍然是这种RESP协议文本。

5.3 端到端演示：删除数据后如何通过AOF还原

理论说了一堆，不如亲手演练一遍完整的“丢数据→恢复”过程。假设你的Redis实例配置了AOF持久化，接下来模拟一次数据丢失：

1. 写入几条数据：

redis-cli SET order:20250101 "paid" redis-cli SET stock:1001 50

2. 确认AOF文件已经有内容：

ls -lh /var/lib/redis/appendonly.aof*

3. 模拟误删数据：

redis-cli FLUSHALL

4. 此时数据已经在内存中清空。但不要慌张，AOF文件里还留着之前的命令。把Redis正常关停：

redis-cli shutdown

5. 重启Redis：

redis-server /etc/redis/redis.conf

6. 检查数据是否恢复：

redis-cli GET order:20250101 redis-cli GET stock:1001

执行完第6步，正常情况应该能取回这两条数据。之所以这么顺畅，是因为从第1步写入到第3步FLUSHALL之间，AOF文件里已经记录了这些命令；重启时Redis按顺序重放这些命令，数据就回来了。

需要提醒的是，如果FLUSHALL之后你又继续写入了其他数据，并且没有做任何处理，那么AOF里既有原来的数据，也有FLUSHALL这个操作。此时重启后，Redis会先重放旧命令，再执行FLUSHALL，最终数据仍然会被清空。生产环境误执行FLUSHALL的常规做法是：立即停掉Redis写入（防止新数据混入），把AOF文件里FLUSHALL相关命令手工删除或截断，再重启恢复。这个操作建议先备份AOF文件后谨慎执行。

6. AOF vs RDB：持久化方案该怎么选

6.1 两种方案的差异化横向对比

RDB和AOF各有各的强项和短板，我把它们的关键差异梳理成一张表，平时做技术选型或者面试准备时都可以直接参考：

这张表里最值得琢磨的是“对性能的影响”这一行。RDB因为平时不做额外IO，所以在纯缓存场景里几乎感觉不到它的存在。AOF则不同，每条写命令都要经过缓冲区、系统调用、甚至是fsync，这确实会带来额外的延迟和IO消耗。但这里要客观一点：在everysec模式下，fsync由后台线程单独处理，主线程的额外开销主要是将命令写入aof_buf，整体影响通常不会让Redis吞吐量出现数量级下滑。很多公司的线上系统跑着everysec，QPS照样能到几万甚至更高。

6.2 不同部署规模下的选型建议

选RDB还是AOF，不能拍脑袋，也不应该搞一刀切。我按常见的几种部署形态给出一套参考策略：

• 纯缓存场景，数据允许丢失，比如验证码、临时会话标识、排行榜缓存等。这种情况可以只开RDB，甚至完全可以不开持久化，每次重启后让数据自然回源。
• 业务数据库的旁路缓存，比如商品的库存、秒杀状态、订单状态。这种场景我建议必须开启AOF，并且使用everysec策略。万一Redis宕机重启，最多丢秒级数据，同时还有RDB作为兜底。
• 订单、流水等一致性要求高、写并发又不算极端的情况。可以考虑appendfsync always，或者对同一份数据同时保留RDB和AOF，RDB用来加速重启时的数据加载（当开启混合持久化时，这一优势已经内建进AOF的base部分）。

另外还要记住一点：选择AOF并开启aof-use-rdb-preamble yes（混合持久化）后，AOF的base文件本身就是一份RDB格式快照，所以“同开RDB”在7.0中已经不像从前那样必要。你的主要决策点是：接受多少丢数据的窗口，以及写性能能承受多大的损失。

6.3 混合持久化的原理与使用建议

混合持久化不是第四种独立的持久化方案，它是AOF重写文件格式的一种优化。开启aof-use-rdb-preamble yes后，BGREWRITEAOF生成的base文件会分为两段：

• 文件头部是RDB格式的全量数据快照，体积小、加载快；
• RDB快照结束之后的部分才是重写期间的增量命令，按AOF格式追加。

这样做的好处非常直观：重启加载时，Redis先按RDB格式快速加载base文件里的全量数据，再重放少量增量命令，恢复速度快了一大截。相比纯AOF模式下要逐条重放几十万、上百万条命令，混合持久化让恢复时间从分钟级下降到了秒级，在实际运维中体验非常明显。

关于混合持久化，我有几点建议：

• 除非有特殊原因，否则建议开启。Redis 5.0及以后版本中aof-use-rdb-preamble默认就是yes，绝大多数场景不需要调整。
• 开启混合持久化后，不要再试图用文本编辑器去修改base文件内容，RDB段是二进制格式，修改一个字节都可能让文件损坏。
• 如果你需要AOF文件可读、可手工修复，那只能关闭混合持久化，回到纯AOF格式。但代价是文件更大、恢复更慢，需要自己权衡。

7. 高频问题排查与故障处理实录

7.1 AOF文件损坏、截断时如何安全恢复

机器突然宕机、磁盘满了、或者有人手工改坏了文件，都会导致AOF文件不完整或损坏。Redis加载时遇到这类问题，表现通常有两种：一是日志里出现类似“Bad file format reading the append only file”的报错，二是进程直接启动失败。

处理方法要看损坏的性质。如果只是文件尾部被截断（比如最后一条命令没写完），并且你的配置是aof-load-truncated yes，那Redis会自动截掉尾部异常内容并正常启动，同时日志里会有警告。这个配置默认是yes，因为它假设尾部的残缺多半是断电导致的。

如果文件中间损坏，或者你想要更可控地处理，建议这样做：

1. 先把坏的AOF文件做备份，不要在原文件上直接操作。
2. 使用redis-check-aof工具修复。它是一个随Redis一起安装的命令行工具，用法如下：

redis-check-aof --fix appendonly.aof

3. 工具会扫描文件，找出第一条格式错误的命令，并询问你是否截断到这条命令之前。输入yes确认后，它会生成一个修复后的文件。
4. 确认修复后的文件能正常加载，再替换原文件，重启Redis。

这个方法我实际用过一次。某次磁盘写入异常导致AOF文件的incr部分出现了半个命令，Redis启动时直接报错。用redis-check-aof --fix处理后，数据恢复到了损坏点之前的状态，损失可控。

7.2 everysec模式下的数据丢失窗口真的只有1秒吗

官方文档说everysec模式最多丢失1秒的数据，但真实场景远比1秒复杂。我来拆解一下这句话到底在什么前提下成立。

每秒钟后台线程会调用一次fsync把页缓存刷入磁盘。假设在第0.8秒时，Redis写入了1万条新命令，这些命令进入了页缓存。如果在第0.9秒时整机断电，那这1万条还在页缓存里的数据就会丢失。从时间跨度看确实不到1秒。

但这里有几个细节容易被忽视：

• 如果磁盘负载过高，fsync本身可能会卡顿甚至等待几秒才能完成，这就可能让实际丢失的时间窗口超过1秒。
• 如果Redis进程本身崩溃而不是整机断电，那页缓存里的数据还在，由操作系统继续负责落盘，这时候基本不会丢数据。
• 如果操作系统自身异常，比如内核panic，那页缓存是否来得及落盘就看运气了。

所以“最多丢1秒”是一个理想条件下的估算值，实际生产中应该带着“在正常磁盘状况下，最多丢秒级数据”这样的认知来评估业务风险。

7.3 AOF重写期间系统资源异常飙升的处理思路

AOF重写带来的性能问题，最典型的是fork瞬间的内存和CPU抖动。fork一个大小几十GB的Redis进程，虽然内存页是共享的，但页表本身的复制也需要时间和内存开销。特别是当Redis实例内存很大、而宿主机内存余量不足时，fork可能触发swap，导致延迟陡增。

遇到AOF重写导致的资源问题，我的处理顺序是：

1. 先看日志确认触发原因。如果是自动触发的，检查是不是auto-aof-rewrite-percentage设置得过小，导致频繁重写。
2. 确认是不是有多个Redis实例同时触发了重写。如果有，把各实例的自动触发阈值错开，避免fork时间点重叠。
3. 如果重写频率过高但文件不大，可以调大auto-aof-rewrite-min-size和auto-aof-rewrite-percentage，手动控制重写节奏。
4. 如果是fork瞬间延迟升高，可以让Redis绑定在多个CPU核上，并确保系统内存充足，避免swap。在容器环境下，尤其要注意内存limit不要刚好卡在redis自身内存的边缘。

另外提醒一句：Redis 7.0为了解决AOF重写期间磁盘占用翻倍的问题，引入了多文件AOF管理机制。重写时不再生成一个巨大的临时文件然后又rename，而是管理base和incr文件的组合，磁盘峰值占用大幅下降。如果你还在用4.0或5.0版本并且被这个问题困扰过，升级到7.0之后会明显感觉到改善。

7.4 主从架构下AOF的特殊注意事项

主从复制环境中，AOF的处理逻辑跟单机略有不同。

如果你从节点开启了AOF，从节点在与主节点完成全量同步后，会把自己的AOF文件清空并重新生成。这本身是正常的，但要注意：从节点的AOF记录的是它自己执行过的写入命令，而这些命令来自主节点的复制流，并非客户端直接写入。所以在排查从节点数据与主节点不一致的问题时，不能只看AOF里的内容，要结合复制偏移量（master_repl_offset）来确认同步进度。

另一个高发问题发生在主从切换后。旧主节点重新加入集群成为从节点时，如果它本地还带着一份比新主节点更“新”的数据（实际是切换期间积压了未同步的写命令），Redis会通过复制协议强制让旧主丢弃本地数据，重新从新主节点全量同步。这时候旧主节点自己生成的AOF内容会被清空重建，如果还有人以为“AOF写着数据就不会丢”，就可能产生误判。

我的建议是：在主从架构中，持久化的职责最好明确划分。通常主节点负责AOF持久化保护数据，从节点主要承担读流量和容灾。如果你在从节点也开启了AOF，请明确它的作用是为了从节点本地的快速恢复，而不是作为主节点的备份依据。

8. 写在最后的几点实践心得

写到这里，关于AOF的机制已经从头到尾过了一遍。最后分享几个我在实际项目中沉淀下来的习惯，供参考。

第一，每次调整AOF配置后，不要只信配置文件，要实际重启一次并确认配置生效。用CONFIG GET appendonly和CONFIG GET appendfsync查看运行时的实际值，比看文件更靠谱。很多时候配置文件里的参数没有生效，是因为实例是通过命令行参数或者外部配置中心启动的，把修改写在了另一个文件里。

第二，给AOF文件和RDB文件的所在目录规划独立的磁盘空间，不要跟系统盘放在一起。AOF增长速度快，如果磁盘写满，Redis会进入保护逻辑，写命令会报错甚至拒绝服务。这类问题在半夜最容易发生，提前用监控告警把磁盘占用率盯起来。

第三，在做AOF恢复演练时，尽量模拟真实故障。别只测正常shutdown然后重启的过程，那是最理想的情况。试试直接kill -9杀掉进程、试试拔掉虚拟机的网卡、试试断电后重启宿主机，看看Redis在那之后能不能恢复、丢了多少数据。这个测试结果会让你对自己系统的持久化能力有一个清醒的认识，也会逼着你把AOF策略打磨得更加稳妥。

AOF本身并不复杂，但它背后牵扯着操作系统、磁盘IO、进程模型和Redis自身的架构演进。把它搞懂，不只是为了应付面试里的几道八股题，更是为了在关键时刻能救你的数据一命。