AOF文件越写越大是因为Redis将每个写命令追加到文件末尾且不自动删除或压缩历史命令触发重写需同时满足auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置并依赖写流量与appendonly yes开启。为什么AOF文件会越写越大AOF本质是把每个写命令追加到文件末尾不删旧、不压缩时间一长自然膨胀。Redis不会自动清理历史命令——比如SET key1 val1之后又SET key1 val2AOF里两条都留着再比如INCR counter执行1000次AOF就记1000行。这不是bug是设计使然保证重放精确性。真正触发重写的不是文件大小本身而是配置项auto-aof-rewrite-percentage和auto-aof-rewrite-min-size共同作用的结果。前者是“当前AOF大小比上次重写后增长了多少百分比”后者是“绝对下限”。两个条件必须同时满足才会触发BGREWRITEAOF。如何让BGREWRITEAOF真正生效很多人配了参数却没看到重写发生核心原因是Redis只在有“写流量”且“AOF已启用”时才检查是否该重写。如果实例刚启动、还没执行过任何写命令或者appendonly no那配置再对也没用。appendonly yes必须开启否则压根不生成AOF文件确保至少有一次成功写入哪怕只是SET a b否则aof_current_size为0百分比计算失效检查CONFIG GET auto-aof-rewrite*确认实际加载的值某些版本会忽略注释后的空格导致配置未生效重写过程本身不阻塞主线程但会fork子进程内存不足或写时复制COW压力大会失败日志里会出现Cant rewrite append only file: No space left on device或Failed to fork重写后AOF变小但数据没丢重写不是简单去重而是“读取当前内存快照 过滤冗余命令 生成最小等效指令集”。例如key被多次覆盖只保留最后一次list被LPUSH又LPOP可能直接消失甚至整个key被DEL掉就不会出现在新AOF里。但要注意EXPIRE类命令不会被重写进新AOF——过期时间由Redis内部维护重写只保留“最终存活的键值对”。所以重写后AOF更小不代表丢了逻辑只是去掉了中间态噪音。 VWO 一个A/B测试工具