1. 从一次“AOF文件越写越大”的故障说起先聊一个我实际遇到过的场景。有段时间线上Redis实例的内存使用率一直平稳但AOF持久化文件却像吹了气球一样疯长从最初的几百MB一路飙到好几个GB。彼时磁盘告警、主从全量同步耗时变长、重启恢复时间越来越不可接受最后排查下来问题就出在AOF文件长期没有重写旧命令越积越多文件里充斥着大量已经被覆盖或删除的key的历史操作记录。那次事故之后我把Redis持久化机制尤其是AOF文件重写这块彻底啃了一遍。很多人对Redis持久化的理解停留在“RDB快照”和“AOF日志”这两个名词上知道AOF是追加写命令日志但真正问到“AOF文件为什么需要重写”“重写到底做了什么”“什么时候触发重写”“重写会不会阻塞主线程”能讲清楚的人并不多。这篇文章我就以AOF文件重写为主线结合我实际操作系统、排查问题、调优参数的完整经过把这块掰开揉碎讲清楚适合正在学习Redis持久化机制、准备面试、或者在生产环境里被AOF文件膨胀困扰的同学参考。1.1 AOF持久化的基本盘先花两分钟把AOF的基本原理理一遍后面讲重写才有基础。Redis默认开启的是RDB快照持久化它会定期把内存中的全量数据生成一份二进制快照。RDB的优点是恢复快、文件紧凑缺点也明显快照之间有数据丢失窗口。AOFAppend Only File则是另一种思路它把每一条修改数据的写命令以Redis协议文本的形式追加到文件末尾重启时逐条重放这些命令就能恢复出内存数据。我个人对AOF的评价是“可靠但笨重”。可靠在于只要配置得当它可以把数据丢失窗口压缩到1秒甚至更低笨重在于命令日志是逐条追加的同一份数据如果被改了一千次AOF里就有一千条记录。长此以往文件必然膨胀于是就有了“文件重写”这个机制来兜底。AOF相关的基础配置有这几个先用表格列一下配置项默认值说明appendonlyno是否开启AOF持久化appendfilenameappendonly.aofAOF文件名appendfsynceverysec日志落盘策略always/everysec/noauto-aof-rewrite-percentage100自动重写触发阈值增长率auto-aof-rewrite-min-size64mb自动重写触发阈值最小体积aof-load-truncatedyes启动时是否容忍AOF文件尾部截断aof-use-rdb-preambleyes是否使用混合持久化格式appendfsync这个参数直接决定数据的可靠性。always表示每条写命令都同步刷盘最安全但性能最差everysec表示每秒刷一次盘性能和可靠性比较均衡这也是生产环境用得最多的no表示交给操作系统决定何时刷盘性能最好但丢失窗口最大。我没少见过有人把appendfsync设成always之后整个Redis写性能直线下降然后跑来问是不是机器不行——其实只是落盘策略选错了。1.2 为什么AOF必须要有“文件重写”这个操作理解了AOF“逐条追加写命令”的本质就不难理解文件为什么会膨胀。举个我自己测试时的例子往Redis里写入一个list反复往里面push再pop再或者频繁更新同一个用户的信息字段。这些操作在AOF里会留下大量中间结果的写命令。AOF文件里存的是“过程”而不是“结果”只要过程足够多文件就会足够大。文件膨胀带来一连串问题磁盘空间占用过高监控告警频繁重启恢复时Redis要逐条重放所有命令恢复时间可能从几秒变成几分钟主从复制时从库加载AOF同样耗时全量同步窗口拉长排查问题时打开AOF文件里面全是无关紧要的中间命令真正有用的数据被淹没。AOF文件重写要解决的核心问题就是“把过程日志压缩为结果快照”。它并不去修改现有的AOF文件而是直接根据当前内存里的数据状态生成一份新的、最小化的写命令集合用这份压缩后的命令集替换掉旧的AOF文件。这里有一个关键认知要纠正很多人以为AOF重写是“遍历旧AOF文件删掉多余命令”实际完全不是。重写的起点是“当前内存中的数据”不是“旧日志文件”。严格来说重写就是一个fork子进程读取当前Redis内存中的数据快照为每个key生成一条最精简的写入命令写到临时文件里最后用临时文件原子替换旧文件。这么说吧旧AOF文件哪怕里面堆积了一百万条对同一个key的写操作重写之后也只会留下一条这个key最终状态的写入命令。这就是“压缩”的本质从过程日志退回到结果快照。2. 深入AOF重写机制子进程、写时复制与缓冲区的三重配合2.1 为什么重写必须fork子进程去做如果AOF重写在主线程里直接遍历内存数据并写文件这个过程中Redis将完全无法处理任何读写请求。对于生产环境来说这是不可接受的。所以Redis的做法是fork一个子进程让子进程去完成数据遍历和文件写入主线程继续服务客户端命令。这里涉及一个非常重要的系统机制fork的空间效率问题。有人会担心fork子进程之后子进程读取父进程的内存数据是不是要把整个Redis内存复制一份实际上Linux的fork结合了写时复制Copy-On-WriteCOW技术子进程创建时和父进程共享同一份物理内存页并不复制内存内容。只有在一方真正要对某个内存页进行写入时系统才会把这一页复制一份给写入方这就是“写时复制”的含义。在AOF重写的场景里子进程只读内存、写文件所以绝大多数内存页是父子共享的真正的物理内存复制量很小。但要注意如果重写期间主线程收到大量写命令触发了大量内存页的写入那么这些页就会被复制内存占用会瞬时上升。这一点在生产环境中影响很大后面我会专门讲。fork子进程的代价在于fork瞬间的耗时fork需要复制内核数据结构、页表等内存越大的实例fork耗时越长。我实测过一个约6GB内存的Redis实例fork耗时大约在几百毫秒到1秒之间。所以如果你的Redis内存很大、又频繁触发自动重写fork带来的毛刺是不可忽视的。2.2 重写期间新写入的命令怎么办AOF重写缓冲区AOF重写不是瞬间完成的遍历一个几GB的实例并生成新文件通常需要数秒到数十秒。这个过程中Redis主线程仍然在接受新的写命令这些命令如果完全不记录重写完成后数据就会丢失如果既写入旧AOF文件又不管新文件那么新文件的内容就和当前数据不一致。Redis的解决方案是引入AOF重写缓冲区aof_rewrite_buf。它的工作机制可以这样理解fork出子进程的那一刻Redis内部同时维护两个缓冲区一个是正常的AOF缓冲区aof_buf用于把写命令追加到旧的AOF文件另一个是专门的AOF重写缓冲区aof_rewrite_buf用于记录重写期间新增的写命令。子进程遍历内存数据、生成命令并写入临时文件这个过程和主线程互不干扰。子进程写完临时文件后会向主线程发送一个信号通知完成。主线程收到信号后把AOF重写缓冲区里的所有命令追加到临时文件的末尾。最后用这个临时文件原子替换旧的AOF文件重写完成。这里最容易被忽略的细节是重写期间新写入的命令在主线程看来是“双写”的——既进了旧AOF文件也进了重写缓冲区。所以重写期间的数据安全性并没有折扣旧AOF文件在替换完成之前一直是完整可用的。万一子进程重写失败旧AOF文件照常使用数据一点不丢。我还在一个细节上踩过坑主线程把重写缓冲区数据追加到临时文件这个阶段是阻塞主线程的。虽然缓冲区数据量一般不大通常只有重写期间积累的命令但如果重写期间QPS特别高缓冲区里积压了几万甚至几十万条命令一次追加也可能耗时较长。所以在高写入场景下AOF重写是有阻塞风险的后面调优部分我会给出我的建议。2.3 重写算法怎么给每个key生成最小化的命令子进程遍历内存数据为每个key生成写命令时实际用的是类似RDB序列化的逻辑。不同类型的key生成的命令格式不同字符串类型直接生成一条SET key value命令List类型生成多条RPUSH key value1 value2 ...命令把所有元素一次性推入Hash类型生成一条HMSET key field1 value1 field2 value2 ...命令Set类型生成一条SADD key member1 member2 ...命令ZSet类型生成一条ZADD key score1 member1 score2 member2 ...命令。对于元素数量很大的集合类型Redis不会一次性把所有元素塞进一条命令而是按一定数量拆分分批写入。这是为了控制单条命令的体积避免一些客户端或协议层面的问题。还有一个细节如果一个key已经设置了过期时间子进程在生成命令时会额外生成一条PEXPIREAT key timestamp把这个过期时间原样保留。所以AOF重写后key的过期语义不会丢失。另外如果Redis开启了aof-use-rdb-preamble默认开启Redis 4.0以后那么生成的新AOF文件开头会是一段RDB二进制格式的数据用来快速加载后面再追加一段AOF格式的命令作为RDB加载完之后的增量补充。这就是所谓的“混合持久化”格式。混合格式的优点是文件体积更小、重启恢复更快缺点是对老版本Redis不兼容如果你有跨版本迁移的诉求需要留意这个配置。3. 实际操作AOF重写的触发方式、参数调优与全过程监控3.1 手动重写与自动重写触发条件详解AOF重写有两种触发方式手动重写和自动重写。手动重写很简单在命令行执行redis-cli BGREWRITEAOF执行后Redis会异步fork子进程进行重写命令会立刻返回Background append only file rewriting started。手动重写适用于你明确知道AOF文件膨胀严重、需要马上压缩的场景比如大促前主动压一遍或者日常巡检发现文件增速异常。自动重写则依赖两个配置参数auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。这两者的含义要准确理解auto-aof-rewrite-percentage的默认值是100表示**AOF文件当前体积相对于“上次重写后体积”的增长率超过100%**时触发重写。auto-aof-rewrite-min-size的默认值是64mb表示AOF文件的绝对体积至少要达到64mb才会考虑重写。两个条件需要同时满足才会触发自动重写。举个例子上次重写完成后AOF文件是100MB当AOF文件再次增长到200MB以上增长率超过100%且超过64MB阈值就会触发重写。如果上次重写后文件是1GB那么下一次触发点是2GB以此类推。auto-aof-rewrite-min-size存在的意义是避免在AOF文件还很小时频繁触发重写毕竟文件小的时候重写收益不大。比如一个实例刚启动不久AOF才30MB增长翻倍也就60MB重写一次省下的空间有限却要白白fork一次子进程不划算。我在线上常用的配置组合是这样appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 1gbmin-size调到1GB是因为我们这些实例的内存普遍在10GB以上AOF文件小于1GB时重写意义不大反而增加不必要的fork开销。如果你是小内存实例比如几百MB建议维持默认64mb。3.2 核心参数解析从appendfsync到aof-load-truncated需要掌握的AOF核心参数除了前面提到的几个还有两个生产环境中很关键但容易被忽略的。第一个是aof-load-truncated。这个参数默认值是yes含义是如果Redis启动时发现AOF文件尾部不完整比如机器异常断电文件最后一条命令写到一半Redis会截断尾部不完整的数据继续启动。如果设为noRedis会直接启动失败提示你需要手动修复文件。关于这个参数我的建议是如果不是对数据完整性有极端要求保持默认yes就好。很多初学者会把这个参数理解成“自动丢失数据”其实它是尽最大努力保证实例能启动尾部最多只丢极短的命令碎片影响面通常远小于实例宕机。第二个是aof-use-rdb-preamble。前面已经提过默认开启后AOF文件的前半部分是RDB二进制格式后半部分是AOF增量命令日志。这种混合格式最大的优点在于文件体积比纯AOF小很多重启加载时RDB部分可以直接快速加载后面的AOF增量部分再重放恢复速度明显优于纯AOF。如果你在用Redis 4.0以上的版本我建议保持默认开启。但要留意如果你有把AOF文件迁移到老版本Redis用的需求需要确认对方版本支持混合格式。此外还有no-appendfsync-on-rewrite参数默认值是no。它的含义是AOF重写期间要不要暂停正常的AOF刷盘。如果设为yes重写期间AOF缓冲区不落盘数据丢失窗口被放大了但可以减少磁盘IO压力避免重写高峰期磁盘被打满。我的经验是如果磁盘性能一般、重写期间又有大量写入可以临时把no-appendfsync-on-rewrite设为yes但要心里清楚这期间的可靠性是打了折扣的。3.3 从触发到替换一次完整重写的全流程拆解下面我把一次AOF重写的完整流程按时间线拆解方便你对照自己的系统观察和验证。第一步触发重写。手动执行BGREWRITEAOF或自动重写的两个条件同时满足。此时Redis主线程调用rewriteAppendOnlyFileBackground准备开始重写。第二步fork子进程。这一步在主线程中执行父进程调用fork创建子进程。fork完成之前Redis无法处理新命令所以如果fork耗时很长会表现为写请求延迟飙升。fork完成后子进程开始执行rewriteAppendOnlyFile主线程立刻恢复对外服务并开始向AOF重写缓冲区写入新的写命令。第三步子进程遍历内存数据生成新AOF临时文件。子进程主要就是读取内存中各个数据库DB的key按类型生成写命令写入一个临时文件。这个临时文件的名字通常形如temp-rewriteaof-bg-xxx.aof。整个过程中子进程只会读内存和写文件不占用主线程的CPU和IO通道。第四步子进程写完临时文件向父进程发送SIGUSR1信号表示重写完成然后退出。父进程收到信号后进入信号处理函数。第五步主线程在信号处理函数中把AOF重写缓冲区积累的所有命令追加到临时文件末尾然后调用rename系统调用把临时文件改为正式的AOF文件名原子替换旧文件。第六步清理现场——关闭旧的AOF文件句柄删除不必要的临时文件更新部分统计信息。这里有一个值得注意的点在第五步中主线程同时会同步更新AOF文件的写入状态确保替换之后新的AOF文件内容与当前内存状态完全一致。也就说说替换完成的那一刻旧AOF文件和重写产生的新AOF文件在内容上是对齐的之后的新写命令只进入新文件不再双写。再补一个细节AOF重写过程中如果Redis收到了新的BGREWRITEAOF命令会直接忽略因为当前已经有重写在进行。这个“忽略”的行为也体现在info persistence里的aof_rewrite_in_progress状态我们可以通过这个字段判断是否有重写正在进行。3.4 用info persistence查看重写状态几个关键指标解读实操中最常用的命令就是redis-cli info persistence输出里与AOF和重写相关的关键字段我用表格梳理一下字段含义关注重点aof_enabledAOF是否开启0或1aof_rewrite_in_progress是否有重写正在进行当子进程正在执行重写时为1aof_rewrite_scheduled是否有重写等待执行例如RDB快照期间收到的重写请求会排队aof_last_rewrite_time_sec最近一次重写耗时如果耗时过长需要关注CPU/磁盘aof_current_size当前AOF文件总大小与上次重写后的体积对比判断增长率aof_base_size上次重写后的AOF大小自动重写的增长基准aof_buffer_sizeAOF缓冲区大小过大说明写入压力高aof_pending_rewrite是否有等待中的重写任务注意与scheduled区分aof_last_bgrewrite_status最近一次重写是否成功ok或err举一个我在线上排查时实际看到的输出片段aof_enabled:1 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:12 aof_current_size:21474836480 aof_base_size:10737418240 aof_buffer_size:0 aof_pending_rewrite:0 aof_last_bgrewrite_status:ok这个实例的aof_current_size是20GB21474836480字节aof_base_size是10GB增长率正好是100%处在触发重写的临界值附近。后来我调低了写入频率才避免频繁触发重写。还有aof_last_rewrite_time_sec如果持续上涨要警惕是不是实例内存太大导致遍历时间过长。一般来说重写耗时和实例中key的数量、元素总量成正比和单纯的内存占用关系不是绝对线性——因为有的key占内存大比如大字符串但遍历生成命令很快有的key数量极多每条命令还要加协议头部反而更慢。4. 常见问题实录重写失败、阻塞毛刺、文件损坏怎么处理4.1 现象一BGREWRITEAOF执行后一直停在等待状态有次我在测试环境敲了BGREWRITEAOF返回了Background append only file rewriting started但info persistence里aof_rewrite_in_progress一直为0aof_rewrite_scheduled也始终为0这就有问题了。排查了一圈最后发现原因是当时正好有RDB快照在做Redis的规则是同一时间只能有一个fork出来的后台任务RDB快照子进程或AOF重写子进程在跑因此AOF重写被排到了RDB完成之后。这种情况下aof_rewrite_scheduled会被置为1表示有重写任务待执行。所以看到aof_rewrite_in_progress为0不要急着下结论先看一眼aof_rewrite_scheduled是否为1。如果你希望重写尽快执行可以等待RDB快照完成如果确实需要立即重写等RDB完成后再手动触发一次或者调整RDB快照的触发频率错开时间。还有一个更隐蔽的场景如果RDB快照频繁触发比如在save策略比较激进、又配合手动执行BGSAVE的情况下AOF重写可能长期得不到执行机会文件持续膨胀。这时候要去查RDB是否过于频繁而不是死盯AOF参数。4.2 现象二重写期间主线程出现短暂阻塞写延迟突增这个问题我用一张简单的对比来解释。前面讲过重写的最后一个阶段主线程要把重写缓冲区积累的命令追加到临时文件末尾。如果重写期间写入量很大这个阶段的操作就不是毫秒级可能达到几十毫秒甚至更久。有个真实案例某促销活动期间一个Redis实例的写入QPS稳定在5万左右AOF重写从fork到子进程写完用了大约10秒尾巴上主线程追加重写缓冲区命令时命令量达到了几十万条导致主线程阻塞了约800毫秒。这800毫秒对下游来说就是一次明显的毛刺。我的处理方案有三个方向错峰重写手动在业务低峰期执行BGREWRITEAOF避开高写入时段。自动重写虽然能兜底但在大促期间建议临时调高auto-aof-rewrite-percentage降低触发频率。提高auto-aof-rewrite-min-size如果实例很大把min-size从64mb提高到1gb甚至更高减少重写次数。如果无论如何都无法避开重写可以考虑在低峰期把实例的数据迁移到新实例新实例的AOF文件从零开始增长也能变相推迟触发时间。这里要提示一点阻塞和fork耗时是两回事。fork耗时发生在fork系统调用本身也是一个阻塞点而阻塞追加发生在最后的缓冲区追加阶段。两者都要纳入性能排查的视野不要只盯着一处。4.3 现象三启动时报错AOF文件尾部被截断或不完整最常见的场景是服务器异常断电后重启Redis日志里出现类似这样的内容Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix filename这是AOF文件尾部停在了半条命令上。如果你配置的是aof-load-truncated yes默认值Redis会直接截断尾部这半条命令并正常启动如果配置的是noRedis会拒绝启动需要手动修复。修复步骤很标准redis-cli --aof fix appendonly.aof # 或者使用redis-check-aof工具 redis-check-aof --fix appendonly.aof修复工具的原理是扫描AOF文件中的每一条命令把不完整的尾部命令移除。我遇到过一种情况文件损坏点不在尾部而在文件中间比如磁盘坏道这时候redis-check-aof --fix能处理的部分有限可能无法完全修复。所以我的建议永远是把AOF文件的完整备份留好再操作千万别在原始文件上直接修。4.4 现象四重写后从库全量同步数据不一致这个现象比较隐蔽。我在一主二从的架构里做过一次手动重写重写完成后发现一个从库的全量同步出现了问题——主库触发了给从库的全量同步但同步后的数据与主库有些micro差异。排查到最后问题不在AOF重写本身而是另一个关联机制重写替换了AOF文件后主从复制的psync判定的复制积压缓冲区repl_backlog内容没有变但部分旧版本的Redis客户端在连接信息里会记录AOF文件的offset重写替换导致部分老版本解析出现偏差。这种事在老版本Redis4.0以前遇到过新版本基本已经修复。这里提醒一下如果你用的是很老的Redis版本又经常手动重写AOF尽量先升级版本。版本升级本身也是对AOF兼容性最好的保障。5. AOF重写与RDB快照的配合生产环境持久化方案组合拳5.1 RDB和AOF同时开启时的资源竞争生产环境里很多团队会同时开启RDB和AOF这没有问题但需要注意两个持久化任务之间的资源竞争。RDB快照fork子进程进行全量内存遍历写盘AOF重写同样要fork子进程遍历内存。如果两个任务几乎同时触发内存可能瞬时被两个子进程顶上fork的CPU开销和内存翻倍风险会显著上升。我的做法是在配置上让两者错开。一种有效的方式是给save策略和AOF自动重写阈值设不同的时间节奏。比如RDB的定时快照设在整点触发AOF的重写阈值调得宽松一些让AOF重写主要依赖手动触发在低峰期执行。不过这个方案需要运营人员有意识地去执行线上实际执行起来容易漏。另一个思路是如果AOF已经开启且aof-use-rdb-preamble保持默认yes其实RBD快照的很多价值已经被AOF混合格式覆盖了——混合格式的AOF文件本身就内含RDB格式开头重启恢复速度接近纯RDB。在这种场景下可以适当降低甚至关闭自动RDB快照频率减少fork次数。当然是否关闭RDB取决于你对数据可靠性的整体设计这里不展开只提示资源竞争这个点。5.2 大内存实例的fork开销怎么评估前面提到fork耗时和大内存的关系这里给一个实际参考我管理过的实例里8GB内存的Redis fork耗时约200毫秒左右16GB的大key较多的实例fork耗时接近1秒。假如你的实例内存有40GB甚至更高fork瞬间的延迟就不能忽视。如果Redis部署在容器或虚拟机上fork耗时会比裸金属更不稳定。容器场景下的内存限制、CPU限额都可能放大fork的表现波动。我在Kubernetes环境里就遇到过同一份配置、两次重写fork耗时相差三倍的情况。评估fork开销是否可接受可以从两个维度看一是重写期间主线程的P99延迟有没有明显抬升二是fork瞬间是否有RSS内存的瞬时翻倍。用info memory里的used_memory_rss观察fork瞬间的内存变化比猜更靠谱。5.3 调优建议如何让AOF重写对业务影响最小基于我多年和Redis持久化打交道的经验给出一份可以直接“抄作业”的调优清单开启AOFappendfsync设为everysec这是兼顾可靠性和性能的默认选择。auto-aof-rewrite-percentage保持100即可不必刻意调小。调小会导致频繁重写徒增fork开销。auto-aof-rewrite-min-size根据实例实际规格调整。小实例2GB内存以下用默认64mb大实例10GB以上建议提高到512mb到1gb。大促或高写入活动前手动执行一次BGREWRITEAOF把AOF文件压到最小让自动重写的触发点往后推迟。开启监控盯aof_last_rewrite_time_sec、aof_current_size、aof_rewrite_in_progress当文件增长率超过预期时提前干预。关注磁盘容量和IO写压力AOF文件膨胀和重写都会产生大量IO避免和数据备份、日志采集等任务挤在同一时段。还有一个容易忽略的点如果你的业务中对Redis的使用是“缓存为主数据可丢”那AOF的重写压力其实可以通过缩短key的过期时间、定期清理无用key来缓解。key越少遍历越快重写文件越小重写代价越低。6. 扩展从AOF重写延伸到面试与架构设计中常考的深层问题既然标题带上了“Redis持久化”和“AOF文件重写”这样的关键词免不了要讲到面试和系统设计场景中那些最常见的追问。这里我把最常被问到的几个问题整理出来给出我自己的回答思路同时也算是对AOF重写机制的二次梳理。6.1 一个问题AOF重写会不会丢失数据这是很多初学者最关心的问题。答案是不会。子进程在fork之后读取的是fork那一刻的内存快照而fork之后主线程新写入的命令会同时进到AOF重写缓冲区里。子进程写完新AOF文件后主线程负责把缓冲区里的命令追加过来。所以从fork那一刻起到新文件替换旧文件为止所有写命令都没有丢。替换完成后新AOF文件完整反映了当前内存状态。唯一可能有数据丢失窗口的环节是平时正常写AOF时appendfsync不是always每两次刷盘之间如果宕机最后一次刷盘之后未落盘的数据会丢。这个窗口和AOF重写本身没有关系是AOF日常持久化策略本身的特性。6.2 另一个问题AOF重写期间能否执行新的写命令能。整个重写过程中除了fork瞬间和最后追加重写缓冲区这两个阶段主线程都在正常服务请求。fork瞬间需要主线程执行fork系统调用会短暂阻塞但通常很短最后追加缓冲区如果有大量积压也可能造成延迟但不等同于主线程停了。所以AOF重写对业务的影响是“低延迟毛刺”而不是“服务中断”。如果业务对写入延迟极其敏感重写的毛刺也不能接受那么唯一的办法是错峰重写、减少触发频率或者从架构层面让单实例的写入压力降下来。6.3 延伸问题AOF重写频繁怎么办频繁触发AOF重写往往意味着auto-aof-rewrite-percentage和auto-aof-rewrite-min-size设置得太灵敏或者实例的写入量实在太大导致AOF文件瞬间就能翻倍。针对这类情况我建议从“降低触发频率”和“降低重写代价”两个方向入手降低触发频率调大auto-aof-rewrite-min-size和auto-aof-rewrite-percentage。同时检查是否有大量临时key、无用key在快速写入和过期大方向还是治理数据本身。降低重写代价开启aof-use-rdb-preamble使用混合格式缩小文件体积在业务低峰期手动执行重写减少在高峰期自动重写的概率。6.4 架构视角AOF重写为什么有时不能解决文件持续增长问题有次有同事问我为什么刚做完AOF重写文件第二天又涨回去了我看了下实例业务发现这个业务的写模式是“大量写入、过期、再写入”很多key的TTL只有几分钟AOF里存满了过期写命令和定期删除命令。重写后文件小了但几分钟后新一批TTL key的写命令又把文件填满。这种情况的根源不完全是AOF重写问题而是业务模式和持久化策略的匹配问题。如果业务数据本来就转瞬即逝、且允许少量丢失可以考虑完全关闭AOF只靠RDB做粗粒度持久化这样连AOF膨胀的问题都免了。如果必须保留AOF那就要接受文件会反复膨胀的事实把重写触发阈值调整到合理的区间同时监控磁盘容量。7. 个人实操心得与收尾最后再分享一个我在维护这套机制时形成的工作习惯我会把每次AOF重写的触发时间、文件大小变化、重写耗时、重写期间主线程延迟数据记录下来积累一段时间后就能看到规律——哪些业务写模式会快速推高AOF文件哪些时段重写毛刺对业务影响最大。有了这些数据再去做参数调优和运维预案就不会是“拍脑袋”决定而是有据可依。如果你是在学习阶段建议自己动手起一个Redis实例把AOF打开写点数据执行BGREWRITEAOF然后用info persistence观察各项指标的变化。你甚至可以手动制造一个很大的list或hash观察重写前后AOF文件大小的差异。纸上得来终觉浅AOF重写机制的奥妙亲手操作一遍比看十篇文章都来得直接。这套机制并不复杂但它是Redis可靠性体系里承上启下的关键一环值得你花时间彻底搞懂。