根本原因是重写触发条件与业务写入节奏错配，导致“重写→变大→再重写”正反馈；高并发下aof_rewrite_buf锁竞争与COW开销加剧卡顿；重写仅压缩结果，不解决冗余写入源头。
为什么AOF重写会陷入“越重写越膨胀”的死循环
根本原因不是重写逻辑出错，而是重写触发条件与业务写入节奏严重错配。比如 auto-aof-rewrite-percentage 100 配合 auto-aof-rewrite-min-size 64mb，在小实例上因 aof_base_size 初始为 0，实际永不触发；但一旦首次重写完成，aof_base_size 被设为新文件大小，后续只要写入量翻倍就再次触发——而高并发写入本身就会快速填满新文件，形成“重写→变大→再重写→更快变大”的正反馈。
更隐蔽的问题是：重写子进程读取 aof_rewrite_buf 时，若主线程持续高频写入（如每秒数万次 SET），缓冲区频繁扩容、锁竞争加剧，导致重写耗时拉长；期间新增命令不断涌入，最终新 AOF 文件反而比旧的还大。
禁用自动重写 + 人工调度是唯一可控手段
自动重写在高并发场景下本质不可靠，必须关闭并接管时机：
- 把
auto-aof-rewrite-percentage设为0，彻底禁用自动触发 - 用监控指标驱动人工干预：监听
INFO persistence中的aof_current_size和aof_base_size，当比值稳定在 2.5~3.0 且绝对值超 200MB 时，才考虑重写 - 只在业务低峰期执行
BGREWRITEAOF，例如凌晨 2:00–4:00，避开流量高峰和定时任务窗口 - 重写前先用
redis-cli --scan --pattern "hot:*" | wc -l粗略评估热点 key 分布，若发现单 key 占写入量 70% 以上，优先从业务层做幂等或合并（如用INCRBY替代多次INCR）
重写期间性能卡顿的直接诱因与缓解点
卡顿不是因为重写本身，而是子进程与主线程争抢 aof_rewrite_buf 锁 + 写时复制（COW）开销叠加：
- 确认是否真由重写引起：检查
used_cpu_sys_children是否突增，且aof_current_rewrite_time_sec > 30 - 预留足够内存：若 Redis 占用内存超 10GB，确保系统空闲内存 ≥ 20%，否则 fork 后 COW 易触发 swap
- 启用
aof-rewrite-incremental-fsync yes，让子进程分批刷盘，避免一次性 I/O 峰值 - 避免在重写过程中执行
DEBUG RELOAD或大规模FLUSHDB，这类操作会强制清空重写缓冲区，导致子进程重头开始
真正要防的不是重写，而是冗余写入源头
AOF 重写只是“事后压缩”，它不分析语义，也不过滤中间态。100 次 SET key v1 → SET key v2 → … → SET key v100，重写后仍是 1 条 SET key v100；但若这 100 次写入来自重复提交或未校验的幂等逻辑，问题就永远存在。
- 对计数类操作，统一用
INCRBY或HINCRBY，避免 N 次GET+SET轮询 - 对列表类操作，用
LPUSH key a b c一次推多个元素，而非循环调用LPUSH key a - 对已明确要删除的 key，不要先
DEL再SET，直接SET覆盖或用UNLINK（异步删） - 定期用
redis-cli --bigkeys扫描长期未更新的 bigkey，它们在重写时会拖慢整个过程
重写不是万能的清理开关，它只认最终内存状态。写入逻辑不干净，重写再勤快也压不住日志膨胀。
