aof文件越变越大是因为持续追加写命令产生大量冗余指令，如重复修改、删除重建、多次增删集合等，导致文件膨胀、恢复慢、磁盘内存占用高。

为什么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 1gb
auto-aof-rewrite-percentage 80

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

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

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

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 检查剩余磁盘空间是否 ≥ 当前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能否稳定在预期水位”。这取决于你是否关掉了无谓的刷盘、是否让过期机制真正起效、以及是否给重写留出了足够冷静的生长周期。