redis aof重写需同时满足aof_current_size≥aof_base_size×(1+percentage/100)且≥min-size，缺一不可；默认100和64mb易致中大型实例每小时多次重写，推荐设min-size为1gb、percentage为80以平衡频率与体积。

默认的 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb 在中大型生产实例上基本等于“定时自爆”——每小时重写多次，IO打满、缓冲区溢出、主从延迟飙升都是常态。

为什么两个参数必须同时满足才触发重写

Redis 的 AOF 自动重写是“与”逻辑：只有当 aof_current_size >= aof_base_size * (1 + auto-aof-rewrite-percentage / 100) 且 aof_current_size >= auto-aof-rewrite-min-size 时，才会真正触发。缺一不可。

常见翻车点：

• 把 auto-aof-rewrite-percentage 调高到 1000（10 倍才触发），但 auto-aof-rewrite-min-size 还留着默认 64mb → 小流量实例天天重写
• 反过来，percentage 设成 100，min-size 却设成 10gb → 大流量实例 AOF 膨胀到 30GB 也不触发，磁盘直接告警
• 单位写错：1024 是 1024 字节，不是 1KB；必须写 1kb、64mb、1gb 才生效

怎么定 auto-aof-rewrite-min-size 才不占爆磁盘

这个值不是“越小越好”，而是要匹配你上次重写完的基线体积 aof_base_size。设太小，会导致重写刚完成就又触发，新旧 AOF 文件双份共存，磁盘瞬间翻倍。

Redis Skill - 高性能缓存管理

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

下载

实操步骤：

• 连上 Redis 执行 INFO persistence，找到 aof_base_size（单位字节）
• 取它的 2–3 倍作为起点：比如 aof_base_size: 524288000（500MB），就设 auto-aof-rewrite-min-size 1gb
• 如果日均写入约 2GB，推荐直接从 1gb 起步；实时计数类场景（写入密集），可设 2gb
• 严禁设 64mb 或 1mb —— 这是新手最常踩的坑，不是“下限”，是“值得重写的门槛”

auto-aof-rewrite-percentage 为什么建议调成 80 而不是 100

设成 100 意味着“翻倍就重写”，但 AOF 刚重写完体积最小，高峰期几分钟就涨到 1.8 倍，接着连续触发。而 80 表示“增长 80% 就重写”，相当于在 aof_base_size 基础上多攒 0.8 倍增量再行动，节奏更稳。

适用场景差异：

• 写入稳定可预测（如常规缓存更新）：优先调 auto-aof-rewrite-percentage，min-size 设为基线的 1.5 倍
• 写入不规律（如夜间批量导入、活动秒杀）：把 percentage 降到 30–50，min-size 提高到基线的 3 倍以上，防毛刺误触发
• 观察 INFO persistence 中的 aof_current_size 和低峰期增长速率，取 2–3 小时自然增长量的 1.5 倍反推 min-size

真正难的不是算数字，而是理解 aof_base_size 是动态基线——每次重写后它就重置。所以配置不能一劳永逸，得结合业务写入节奏和 INFO persistence 的实际输出来滚动调整。