AOF重写是否执行需查INFO persistence中aof_rewrite_in_progress=1；其进度不可实时获取，仅能通过aof_current_rewrite_time_sec、临时文件大小及系统IO/CPU指标间接观测，无内置key级进度统计。
Redis本身不提供AOF重写过程的实时进度百分比，但可通过组合命令和指标间接观测状态与开销。
如何判断AOF重写是否正在执行
直接查 INFO persistence 的输出字段：
-
aof_rewrite_in_progress:1表示当前有重写子进程在运行；为0则没有 -
aof_rewrite_scheduled:1表示重写已被调度但尚未开始（例如因no-appendfsync-on-rewrite yes正在等待 fsync 完成） -
aof_current_rewrite_time_sec是已运行秒数，可粗略反映耗时趋势（但不等于总耗时，因为可能被中断或暂停）
重写期间的内存与IO开销怎么看
AOF重写由子进程完成，其资源消耗主要体现在三方面：
-
内存：子进程会 fork，触发写时复制（COW），实际内存占用取决于重写开始时刻的 Redis 内存脏页量。用
INFO memory对比used_memory和used_memory_rss差值突增，是典型信号 -
CPU：重写本身是 CPU 密集型操作，尤其 key 数量大、value 复杂时。观察系统级
top -p $(pgrep -f "redis-server.*aof")或ps aux | grep "redis.*rewrite" -
磁盘IO：重写生成新文件是顺序写，但若同时开启
appendfsync always或everysec，主线程与子进程会竞争磁盘带宽。用iostat -x 1看%util和await是否飙升
为什么不能像RDB那样用bgsave_info查进度
因为 AOF 重写没有暴露类似 bgsave_in_progress 那样的原子状态字段，也没有内置计数器记录“已处理多少key”。它的实现逻辑是遍历当前数据库键空间，逐个序列化最新值，不维护中间进度快照。所以：
-
redis-cli info persistence | grep aof只能告诉你“在不在干”，不能告诉你“干到哪了” - 不要依赖
aof_base_size和aof_current_size差值估算进度——这两个是触发条件阈值，不是实时大小 - 若需精确监控，得靠外部手段：比如定期
du -h appendonly.aof.*.temp（重写临时文件名通常带.temp后缀），但要注意该文件仅在重写中存在，且权限受限
真正容易被忽略的是：AOF重写过程中，如果配置了 auto-aof-rewrite-percentage 触发机制，而新写入又非常频繁，可能导致连续重写被反复调度，形成“重写风暴”。此时 aof_rewrite_scheduled 会长时间为 1，但 aof_rewrite_in_progress 在 0 和 1 之间跳变，必须结合日志（grep "Background AOF rewrite" redis.log）交叉验证。
