默认配置易致频繁重写，推荐设auto-aof-rewrite-min-size为1gb、auto-aof-rewrite-percentage为80，以匹配日均写入节奏并预留缓冲空间，避免雪崩式重写。
默认的 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb 在中大型生产实例上必然导致每小时多次重写，IO打满、缓冲区溢出、主从延迟飙升是常态——这不是配置没生效，而是它根本就不是为生产设计的。
怎么设 auto-aof-rewrite-min-size 才不频繁重写
这个值必须匹配你的日均写入节奏，而不是拍脑袋填个“1gb”了事。设太小（比如默认 64mb），一个 QPS 2k 的 Redis 实例可能 5 分钟就突破，接着每十几分钟触发一次重写。
- 观察
INFO persistence中的aof_current_size，再盯住业务低峰期（比如凌晨 2–4 点）2 小时内的自然增长量 - 取这个增长量的 1.5 倍作为起点：日均写入约 2GB 的实例，建议从
auto-aof-rewrite-min-size 1gb开始；若写入密集（如实时计数、排行榜更新），直接设2gb - 单位必须带后缀：
1024是 1024 字节，1gb才是 1GB；配置里写错单位会导致策略完全失效
为什么 auto-aof-rewrite-percentage 设 80 比 100 更稳
百分比不是看“绝对增长”，而是对比上一次重写后的 aof_base_size。设成 100 意味着“翻倍就重写”，但 AOF 在重写刚完成时体积最小，之后极易在高峰时段快速膨胀，导致连续触发。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为
80表示“比上次重写后大 80% 就触发”，相当于留出 20% 缓冲空间，避免雪崩式重写 - 该参数仅在
aof_current_size > auto-aof-rewrite-min-size时才参与判断，两者是“且”关系，缺一不可 - 如果你发现重写后
aof_current_size很快又逼近aof_base_size * 1.8，说明写入突增或过期 key 清理不及时，需查maxmemory-policy和EXPIRE命令分布
AOF重写期间磁盘 IO 竞争怎么压
重写期间延迟飙升主因不是主线程阻塞，而是子进程批量写新 AOF + 主线程按 appendfsync 刷盘共争磁盘带宽。磁盘 util > 90% 或 await > 20ms 就已是瓶颈信号。
- 开启
aof-rewrite-incremental-fsync yes：默认子进程攒够 32MB 才调一次fdatasync，容易造成单次刷盘压力过大；开启后每写入 4MB（可配）就刷一次，把大 IO 打散 -
no-appendfsync-on-rewrite yes能缓解，但代价是重写期间宕机可能丢失最多 1 秒数据（取决于appendfsync everysec的窗口） - 检查
client-output-buffer-limit slave：从节点同步慢会卡住aof_rewrite_buffer清理节奏；建议设为"256mb 64mb 60"（软限 256MB、硬限 64MB、超限 60 秒断连）
真正难的不是改那两行配置，而是持续观察 aof_current_size 与业务流量的关系——重写频率永远是动态的，今天合理的值，下周上线新功能后可能就变成定时炸弹。
