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 50Redis并不是直接把这行文本扔进文件。整个AOF写入路径可以分成四个环节命令执行Redis服务器先执行这条命令把内存中的数据真正改掉。协议序列化命令会被转换成Redis自己的网络协议格式RESP说白了就是把命令、参数、参数个数等按特定规则编码成一串文本。追加到缓冲区序列化后的内容先写入内存中的aof_buf缓冲区这个缓冲区是每个Redis服务器进程维护的一块内存区域。刷盘flush根据配置的策略在一定时机把aof_buf里的数据写入操作系统内核的页缓存page cache再调用fsync把页缓存的数据真正写入磁盘。这里最关键也最容易被忽略的是第3步和第4步的区别。你调用write()把数据写入文件这个动作只代表数据交给了操作系统操作系统并不会立刻把它写到磁盘的物理扇区上而是先放进内核的页缓存里。什么时候落盘取决于操作系统自己的调度策略。如果这个节骨眼上机器断电了页缓存里那部分数据仍然会丢。所以AOF刷盘策略里讨论的核心其实是在哪里、以什么频率调用fsync让数据从内核态真正刷到磁盘。3.2 三种刷盘策略的取舍always、everysec、noRedis的appendfsync配置项控制的就是刷盘时机它有三个可选值含义和代价完全不同我用一个例子来说明差异。假设当前有10条写命令已经执行完毕aof_buf里存着这10条命令的序列化结果。always每条命令执行完立刻把aof_buf内容同步刷到磁盘。数据安全性最高最多只丢正在执行的那一条命令严格说命令执行成功但fsync失败的情形除外。代价是每次写操作都要等待一次磁盘I/O吞吐量骤降。实测在这种模式下Redis的写QPS可能只有默认模式的三分之一甚至更低所以它只适合对数据安全极端敏感、且写并发极低的场景。everysecaof_buf会先写入系统页缓存由一个后台线程每隔1秒调用fsync把数据刷到磁盘。这种策略在性能和数据安全之间取了一个平衡。如果机器只是进程崩溃那页缓存里的数据还在最多丢失1秒的写入如果是整机断电则最多丢失约1秒的数据。noRedis只负责把数据交给操作系统完全不主动调用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 counterAOF文件里就会追加10万条INCR counter命令。但实际上这10万条历史命令对最终结果只有一个贡献counter的值加了10万。启动时把这10万条一条条回放效率极低文件体积也臃肿不堪。所以AOF必须有一个机制来压缩日志体积抹掉那些“中间过程”只保留最后的结果。这个机制就是重写。重写得到的并不是对原AOF的修修补补而是基于当前内存中的数据快照生成一组能够重建当前数据集的最小命令集然后写到一个临时文件里最后替换掉旧文件。这样计数器案例中10万条INCR命令就被压缩成了一条SET命令。4.2 重写触发时机与自动重写的判定逻辑重写有两种触发方式手动和自动。手动触发很简单在redis-cli里执行BGREWRITEAOF这条命令会让Redis在后台异步执行重写不会阻塞主服务。自动触发则是由配置的两个参数联合控制auto-aof-rewrite-percentageAOF文件当前体积相比上一次重写后的基准体积的增长比例。默认100表示当文件增长了一倍时会触发。auto-aof-rewrite-min-size触发重写的最小文件体积。默认64mb也就是说就算增长率达到了100%但文件还没有超过64MB也不会触发。举个例子上次重写完成后AOF文件基准大小为100MB。当文件体积增长到超过200MB时因为有auto-aof-rewrite-percentage 100Redis就会在合适时机触发自动重写。如果基准体积很小比如只有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之前写作BGREWRITEAOF7.0之后仍然兼容这个命令但Redis官方也建议直接用它。不要用REWRITEAOF那是阻塞式重写生产环境不推荐使用。5. AOF数据恢复流程文件是怎么变成内存数据的5.1 启动加载顺序与AOF在其中的角色很多人以为Redis启动后是先加载RDB再加载AOF或者两者都加载这其实是误解。Redis的加载规则是如果开启了AOFappendonly yes启动时优先加载AOF如果AOF没开启才尝试加载RDB。绝大多数情况下二者是互斥的不会在同一份数据目录中同时加载两套数据。Redis官方这样设计的原因很简单AOF记录的数据更新、更完整。如果AOF和RDB同时存在却优先加载RDB那相当于用旧数据覆盖新数据。所以在开启AOF的实例中RDB文件更多扮演的是“AOF缺失时的兜底”角色而不是日常恢复的主力。整个启动加载流程大致如下检查appendonly配置项。如果为yes则进入AOF加载流程。读取manifest清单文件确认该实例关联了哪些base文件和incr文件。按顺序加载base文件如果有混合持久化前缀则按RDB格式解析恢复再逐个加载incr文件重放增量命令。所有命令重放完成后数据集构建完毕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持久化接下来模拟一次数据丢失写入几条数据redis-cli SET order:20250101 paid redis-cli SET stock:1001 50确认AOF文件已经有内容ls -lh /var/lib/redis/appendonly.aof*模拟误删数据redis-cli FLUSHALL此时数据已经在内存中清空。但不要慌张AOF文件里还留着之前的命令。把Redis正常关停redis-cli shutdown重启Redisredis-server /etc/redis/redis.conf检查数据是否恢复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各有各的强项和短板我把它们的关键差异梳理成一张表平时做技术选型或者面试准备时都可以直接参考对比维度RDBAOF数据安全两次快照之间最多丢数分钟数据everysec最多丢1秒always几乎不丢记录粒度周期性全量快照每次写命令的追加日志文件体积紧凑远小于AOF通常较大靠重写压缩恢复速度快直接加载二进制快照慢需要逐条重放命令对性能的影响快照fork时有一定开销日常无额外写入每条写命令都有额外写日志的开销适合场景缓存、可重建数据、对恢复速度敏感不能丢数据的业务数据、订单、库存等文件可读性二进制不可读文本协议可读可修改关闭混合模式时这张表里最值得琢磨的是“对性能的影响”这一行。RDB因为平时不做额外IO所以在纯缓存场景里几乎感觉不到它的存在。AOF则不同每条写命令都要经过缓冲区、系统调用、甚至是fsync这确实会带来额外的延迟和IO消耗。但这里要客观一点在everysec模式下fsync由后台线程单独处理主线程的额外开销主要是将命令写入aof_buf整体影响通常不会让Redis吞吐量出现数量级下滑。很多公司的线上系统跑着everysecQPS照样能到几万甚至更高。6.2 不同部署规模下的选型建议选RDB还是AOF不能拍脑袋也不应该搞一刀切。我按常见的几种部署形态给出一套参考策略纯缓存场景数据允许丢失比如验证码、临时会话标识、排行榜缓存等。这种情况可以只开RDB甚至完全可以不开持久化每次重启后让数据自然回源。业务数据库的旁路缓存比如商品的库存、秒杀状态、订单状态。这种场景我建议必须开启AOF并且使用everysec策略。万一Redis宕机重启最多丢秒级数据同时还有RDB作为兜底。订单、流水等一致性要求高、写并发又不算极端的情况。可以考虑appendfsync always或者对同一份数据同时保留RDB和AOFRDB用来加速重启时的数据加载当开启混合持久化时这一优势已经内建进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因为它假设尾部的残缺多半是断电导致的。如果文件中间损坏或者你想要更可控地处理建议这样做先把坏的AOF文件做备份不要在原文件上直接操作。使用redis-check-aof工具修复。它是一个随Redis一起安装的命令行工具用法如下redis-check-aof --fix appendonly.aof工具会扫描文件找出第一条格式错误的命令并询问你是否截断到这条命令之前。输入yes确认后它会生成一个修复后的文件。确认修复后的文件能正常加载再替换原文件重启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重写导致的资源问题我的处理顺序是先看日志确认触发原因。如果是自动触发的检查是不是auto-aof-rewrite-percentage设置得过小导致频繁重写。确认是不是有多个Redis实例同时触发了重写。如果有把各实例的自动触发阈值错开避免fork时间点重叠。如果重写频率过高但文件不大可以调大auto-aof-rewrite-min-size和auto-aof-rewrite-percentage手动控制重写节奏。如果是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自身的架构演进。把它搞懂不只是为了应付面试里的几道八股题更是为了在关键时刻能救你的数据一命。