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