aof冗余源于写入源头重复命令，重写仅被动压缩；需结合幂等控制、合理配置auto-aof-rewrite参数及低峰期手动干预来减少冗余。
直接启用 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 并不能自动“防止”重复命令产生，它只在膨胀后被动压缩——真正要减少冗余，得从写入源头和重写配置双管齐下。
为什么AOF里总出现大量重复命令
AOF 本身不分析语义，只忠实记录每条写命令。比如对同一个 counter 执行 100 次 INCR，就会记 100 行；又或者反复 SET key v1 → SET key v2 → DEL key，这些历史操作全保留，但最终状态只是“键不存在”。重写前，这些冗余会持续累积。
常见诱因包括：
- 高频更新同一 key（如计数器、缓存状态标记）
- 业务逻辑未做幂等控制，导致重复写入相同值
- 使用
APPEND、LPUSH等命令批量追加但未合并（如分多次LPUSH list a、LPUSH list b而非一次LPUSH list a b） - 未清理已过期或被
DEL的 key，它们仍可能在重写前被反复操作
手动触发 BGREWRITEAOF 的实际效果与风险
执行 redis-cli BGREWRITEAOF 会立即 fork 子进程生成新 AOF，但它不是“实时去重”，而是基于当前内存快照重建命令。这意味着：
- 它能合并
INCR成SET、把多次LPUSH合成一条（最多 64 元素/条，防客户端缓冲区溢出） - 它会跳过已过期或被
DEL的 key，也不会记录EXPIRE命令（除非 key 仍有效） - 但它无法修正你刚写进去的冗余——比如重写开始前 1 秒内写的 10 条
SET，子进程看不到中间态，只看到最终值，所以仍只写 1 条 - 若此时主进程正在写 bigkey，fork 可能触发写时复制（COW），造成短暂延迟甚至阻塞
所以别指望靠频繁手动重写“擦除”刚发生的冗余；它更适合在低峰期主动干预，或作为监控告警后的应急手段。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 怎么配才不翻车
默认配置（auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 64mb）在小数据量实例上几乎永不触发——因为 aof_base_size 初始为 0，第一次重写后才设为实际大小。结果就是：AOF 文件涨到 200MB 了，aof_current_size / aof_base_size 算出来是 Inf，但 Redis 实际判断逻辑是 “必须同时满足 > min-size 且增长百分比达标”，而 aof_base_size == 0 时，百分比条件恒为 false。
正确做法是：
- 首次部署后，先手动执行一次
BGREWRITEAOF，让aof_base_size落地为真实初始体积 - 把
auto-aof-rewrite-min-size设为略高于你预期的“稳态 AOF 大小”，比如 32mb 或 64mb，避免小文件频繁重写 -
auto-aof-rewrite-percentage不建议调太高（如 200），否则等触发时 AOF 已膨胀到难以接受；100 是平衡点，75 更激进但会增加重写频次 - 务必开启
no-appendfsync-on-rewrite yes，否则重写期间appendfsync everysec可能被阻塞，导致 aof_buf 积压、延迟飙升
重写期间的增量命令怎么不丢不乱
重写不是原子切换，而是三阶段接力：子进程写新文件 → 主进程把重写期间的新命令存进 aof_rewrite_buf → 子进程完成后再由主进程追加到新文件 → 最后 rename()。这个设计保证了数据不丢，但要注意：
-
aof_rewrite_buf是纯内存缓冲区，如果重写耗时过长（比如几百 MB AOF + 大量写入），它可能吃光内存，引发 OOM - Redis 不会压缩
aof_rewrite_buf里的命令，它原样追加，所以如果你在重写过程中狂刷 1000 次INCR，这 1000 行还是会进新 AOF（尽管最终值只用 1 条SET就能表达） - 可通过
info persistence实时看aof_rewrite_buffer_length，若持续 > 10MB，说明写入压力大，需考虑降频或拆分 bigkey - 重写完成前，旧 AOF 文件仍正常追加，所以磁盘空间必须预留至少 2 倍当前 AOF 大小
真正难处理的不是重写本身，而是重写窗口期内的写入模式——如果业务层无法收敛重复操作，再好的重写机制也只能做“事后清扫”，而不是“事前拦截”。
