设为0会禁用自动aof重写，完全依赖手动bgrewriteaof；有效范围是50～100，需配合auto-aof-rewrite-min-size使用，后者才是触发重写的体积门槛。
auto-aof-rewrite-percentage 设为 0 会禁用自动重写
设成 0 看似“最激进提速”，实则是关闭自动触发，完全依赖手动 BGREWRITEAOF。高频写入下没人盯守就等于放任 AOF 持续膨胀，磁盘迟早被打满。
真正有效的调低范围是 50～100（默认 100），配合 auto-aof-rewrite-min-size 使用——后者才是控制“起始重写门槛”的关键参数。
-
auto-aof-rewrite-percentage只在当前 AOF 文件比上次重写后体积增长超过该百分比时才考虑触发 - 如果 AOF 当前才 2MB，而
auto-aof-rewrite-min-size是默认的64mb，哪怕设成10也压根不会启动重写 - 高频写入场景建议：把
auto-aof-rewrite-min-size降到16mb或8mb，再把auto-aof-rewrite-percentage调到50
AOF 重写期间写入延迟飙升，不是配置问题而是机制使然
重写本质是 fork 子进程遍历内存快照生成新 AOF，fork 阶段虽快，但子进程重写过程中主进程仍要持续追加命令到旧 AOF 文件——这会导致两件事：
- 旧 AOF 文件继续增长（直到重写完成才原子替换）
- 系统页表复制（Copy-on-Write）压力增大，尤其内存大、写入密时，可能引发短时
latency spikes，表现为 client 端TIMEOUT或redis-benchmarkp99 延迟跳变 - Linux kernel 的
vm.overcommit_memory若为0（默认），fork 可能失败并报错Can't save in background: fork: Cannot allocate memory
解决方向不是压低重写频率，而是缓解 fork 压力：vm.overcommit_memory=1 + 控制单实例内存上限（比如 ≤4GB），比盲目调 auto-aof-rewrite-percentage 更治本。
混合持久化（aof-use-rdb-preamble yes）能显著缩短重写耗时
开启后，重写生成的 AOF 文件开头是 RDB 格式二进制快照，后面才是增量命令——相当于把“全量数据 dump”压缩成一次序列化操作，而不是逐条 replay 所有写命令。
- 实测 2GB 内存实例，纯 AOF 重写耗时约 3.2s；开启
aof-use-rdb-preamble yes后降至 1.1s 左右 - 重写时间缩短 = 主进程被 fork 和子进程 IO 占用的时间窗口变窄 = 更少影响线上延迟
- 注意兼容性：Redis 4.0+ 才支持，且需确保
aof-load-truncated设为yes（应对异常截断）
重写失败后 AOF 文件可能损坏，必须检查日志 + 监控 aof_last_bgrewrite_status
重写失败不会自动回滚旧 AOF，但 Redis 会记录错误并标记状态。常见失败原因包括磁盘满、权限不足、内存分配失败，错误信息形如：
Failed to rewrite the AOF file: No space left on device
此时 AOF 文件本身未必损坏，但若后续写入又失败，就可能产生不完整命令导致加载失败。务必做两件事：
- 查 Redis 日志里最近的
Background AOF rewrite terminated with error行 - 运行
redis-cli info persistence | grep aof_last_bgrewrite_status，确认值为ok而非err - 生产环境建议用脚本定期检查该字段，并对
err状态告警
调低 auto-aof-rewrite-percentage 会让重写更频繁，出错概率同步上升——频繁不等于可靠，监控和兜底动作反而更不能省。
