Redis持久化AOF文件过大 配置自动重写策略

关于AOF文件越变越大的问题，核心矛盾其实就一句话：持续追加写命令，导致大量冗余指令堆积。比如重复的SET、重复的删除重建、反复增删集合元素——这些操作被原封不动地记下来，文件自然越来越臃肿。重启时Redis要逐条重放这些指令，不仅恢复速度慢，还白白占用磁盘和内存。

为什么AOF文件会越变越大

AOF本质上就是个“记账本”——每一条写命令都被原封不动地记下来。比如SET key1 v1、INCR counter、DEL key1，全都原样入账。时间一长，同一个key反复修改、删除重建、list或set多次增删，就会产生大量冗余指令。重启时Redis不得不逐条重放这些命令，不仅恢复慢，还占磁盘和内存。这就像记账时只记流水，不整理，久了账本自然厚得离谱。

auto-aof-rewrite-min-size和auto-aof-rewrite-percentage怎么设才合理

这两个参数共同决定自动重写的触发时机，但默认值（64mb + 100）在生产环境几乎总是太激进：

• auto-aof-rewrite-min-size 64mb：64MB对小实例可能够用，但中大型实例往往几分钟就突破，导致频繁重写，加重IO压力
• auto-aof-rewrite-percentage 100：翻倍就重写，容易在业务高峰期连续触发，尤其当AOF刚重写完又快速增长时

从实际运维经验来看，比较好的调整方向是适当放宽阈值。以日均写入量约2GB的实例为例，推荐配置：

auto-aof-rewrite-min-size 1gbauto-aof-rewrite-percentage 80

这样既避免过早重写，又防止AOF膨胀到3GB以上才行动。注意单位必须带mb或gb，写成1024会被当成字节。

手动执行BGREWRITEAOF前必须确认的三件事

BGREWRITEAOF虽是后台操作，但子进程仍需内存拷贝+磁盘写入，疏忽易引发OOM或IO打满：

• 检查剩余磁盘空间是否 ≥ 当前AOF文件大小的1.5倍（重写期间新旧文件并存）
• 用INFO persistence确认aof_rewrite_in_progress:0，避免并发重写
• 避开流量高峰——重写期间主进程要持续将新写命令写入aof_rewrite_buffer，若此时QPS突增，缓冲区可能溢出，导致客户端连接超时

安全执行方式：

redis-cli -p 6379 BGREWRITEAOF# 然后立刻观察：redis-cli -p 6379 INFO | grep -E "aof_rewrite|used_memory"

重写后AOF没变小？可能是这些配置被忽略了

即使重写完成，AOF体积仍居高不下，常见原因不是重写失败，而是以下配置未生效：

• appendfsync no未启用：若仍为everysec，每次重写后的新AOF文件会立即开始高频刷盘，很快又膨胀
• 过期键未真正清理：AOF重写时会跳过已过期但尚未被惰性/定期删除的key，但若maxmemory-policy设为noeviction，这些“僵尸key”仍在内存里，重写时仍会被写入新AOF
• 存在大量EXPIREAT或PEXPIREAT命令：重写时不会计算绝对过期时间，只保留命令本身，导致新AOF里堆满无效过期指令

验证重写效果最直接的方式是对比重写前后INFO persistence中的aof_current_size与aof_base_size，差值应显著收窄。

真正关键的不是“重写动作是否执行”，而是“重写后的AOF能否稳定在预期水平”。这取决于你是否关掉了无谓的刷盘、是否让过期机制真正起效、以及是否给重写留出了足够冷静的生长周期。