应禁用自动aof重写（auto-aof-rewrite-percentage 0），改由运维在低峰期手动执行bgrewriteaof；同时设auto-aof-rewrite-min-size为256mb、no-appendfsync-on-rewrite yes及aof-rewrite-incremental-fsync yes，确保重写可控、i/o平滑。

要避免 AOF 重写因自动触发导致的 I/O 突发阻塞，关键不是“配置重写脚本”，而是合理设置 auto-aof-rewrite-percentage 及其配套参数，让重写在低峰、可控、资源充裕时发生，而非被小幅度增长反复拉起。

避开高频小重写的陷阱

默认配置 auto-aof-rewrite-percentage 100 意味着只要当前 AOF 文件比上次重写后大一倍就触发。若原文件仅 10MB，增长到 20MB 就重写——此时重写开销虽小，但频繁 fork + 写盘仍会叠加 I/O 压力，尤其在业务写入密集时段。

Redis Skill - 高性能缓存管理

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

下载

• 把阈值调高，例如设为 200 或 300，同时配合足够大的基础尺寸（如 auto-aof-rewrite-min-size 256mb），确保只在真正需要“瘦身”时才重写
• 禁用自动触发更稳妥：auto-aof-rewrite-percentage 0，完全交由运维在凌晨或低峰期手动执行 BGREWRITEAOF，彻底规避不可控的突发

防止重写本身加重 I/O 压力

即使重写被正确触发，若磁盘扛不住，仍会出现卡顿。这不是百分比配置的问题，而是需联动调优：

• 开启 no-appendfsync-on-rewrite yes：重写期间暂停主线程的 appendfsync，避免 AOF 日志刷盘与重写子进程争抢磁盘 I/O
• 启用 aof-rewrite-incremental-fsync yes（默认已开）：让子进程每写入约 32MB 就执行一次 fdatasync，而不是等全部写完再刷，平滑 I/O 负载
• AOF 文件务必放在独立 SSD 上，不与 RDB、日志或其他数据库共用同一块磁盘

监控先行，别靠猜

光调参数不够，得看实际运行状态才能判断是否真避开了阻塞：

• 定期查 INFO persistence，关注 aof_current_size 和 aof_base_size，确认增长是否符合预期，有无异常抖动
• 观察 aof_rewrite_in_progress 是否长期为 1，结合 aof_current_rewrite_time_sec 判断单次耗时是否超标（如 >30 秒需警惕）
• 检查 used_cpu_sys_children 是否在重写期间突增，这是子进程消耗系统 CPU 的直接信号