光靠bgrewriteaof只能救急，不配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，aof文件必再膨胀至占满磁盘；因其仅一次性压缩，不启用自动机制则后续写入持续累积，且旧文件不自动清理。
直接结论：光靠 BGREWRITEAOF 手动触发只能救急，不设 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，AOF 文件必然再次膨胀到占满磁盘。
为什么手动执行 BGREWRITEAOF 后还会爆盘
你看到 appendonly.aof 从 128GB 缩到 22GB，很爽——但这是“快照式压缩”，只反映当前内存数据的最小命令集。只要业务持续写入，AOF 就继续追加日志，几天后又回到上百 GB。更关键的是：BGREWRITEAOF 不会自动删旧文件，也不改配置，它只是“重写一次”。如果没配自动触发，下一次重写永远不会来。
常见错误现象：
- 执行完
BGREWRITEAOF，temp-rewriteaof-*.aof文件残留，占用空间不释放 - 重写后 AOF 文件大小回落，但一周内又涨回原量级甚至更大
-
redis-cli INFO persistence显示aof_pending_rewrite: 0，但aof_current_size持续飙升，说明自动机制根本没启用
怎么设置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size
这两个参数必须同时生效才起作用。Redis 启动时只读取 redis.conf，运行中修改需 CONFIG SET 并 CONFIG REWRITE 持久化，否则重启失效。
实操建议：
-
auto-aof-rewrite-min-size别设太小：设成64mb是多数场景安全下限；低于此值，即使增长 200%，也不会触发重写（防止小文件频繁重写） -
auto-aof-rewrite-percentage要结合业务写入节奏调：高写入服务（如实时计数、消息队列）建议设为50（增长 50% 就重写），低频服务可保留默认100 - 务必确认
appendonly yes已开启，否则两个参数完全不生效 - 检查
dir配置路径是否有足够空间：重写期间新写入仍追加到旧 AOF，同时子进程生成新文件，**磁盘剩余空间必须 ≥ 当前 AOF 文件大小的 2 倍**
重写期间的磁盘与内存风险点
AOF 重写不是“复制粘贴”，而是 fork 子进程遍历当前数据库状态，重新生成等效命令。这个过程对资源有明确要求：
- 内存：子进程共享父进程页表，但重写过程中若主进程大量修改键（尤其是大 key），会触发写时复制（COW），导致内存翻倍。观察
INFO memory中的mem_allocator和used_memory_rss是否异常上涨 - 磁盘 IO：重写完成前，新写入命令仍追加到旧 AOF 文件，而子进程在写新文件，IO 压力双倍。固态硬盘能扛住，但机械盘可能卡顿甚至超时
- 阻塞风险：重写本身不阻塞主线程，但若磁盘满或 IO 超时，Redis 可能报
Asynchronous AOF fsync is taking too long，此时应立刻检查appendfsync策略是否为everysec（always在高负载下极易拖垮）
验证配置是否真正生效
别只看配置文件写了什么，要确认 Redis 进程实际加载并响应了这些值：
- 连上
redis-cli，执行CONFIG GET auto-aof-rewrite*，输出应为实际生效值，不是空或nil - 执行
INFO persistence，关注这几项：aof_enabled:1（确认开启）、aof_rewrite_in_progress:0（非重写中）、aof_last_rewrite_time_sec（最近一次耗时）、aof_current_size和aof_base_size（用于计算是否满足重写条件） - 模拟增长：用
DEBUG populate 100000 key 1000快速写入，观察几分钟内是否自动触发重写（需满足 min-size + percentage 双条件）
最容易被忽略的一点：重写完成后，旧 AOF 文件不会自动删除，Redis 仅原子替换文件名。如果你看到多个 appendonly.aof.* 或残留 temp-rewriteaof-*.aof，得手动清理——但前提是确认新文件已成功载入且服务正常，否则删错就丢数据。
