AOF重写会拖慢主从同步，因其fork子进程遍历内存生成新日志，与主进程处理写命令、复制积压缓冲区争抢CPU和磁盘IO资源；尤其在磁盘慢或内存大时，bgrewriteaof卡顿导致主节点响应变慢、从节点收不到新命令，offset差值迅速拉大。
为什么AOF会拖慢主从同步
AOF本身不直接导致主从延迟，但它的重写（bgrewriteaof）过程会显著加剧延迟。主节点在执行AOF重写时会fork子进程，该子进程要遍历整个内存数据生成新日志文件；与此同时，主进程仍需持续接收写命令、追加到旧AOF缓冲区，并处理复制积压缓冲区（repl-backlog）。这两件事争抢IO和CPU资源，尤其当磁盘慢或内存大时，bgrewriteaof可能卡住几秒甚至更久，期间主节点响应变慢，从节点收不到新命令，master_repl_offset和slave_repl_offset差值迅速拉大。
配置项 no-appendfsync-on-rewrite yes 必须开
这是最直接有效的规避手段。默认情况下，主进程在AOF重写期间仍每秒调用fsync()（因为appendfsync everysec），而重写本身已占满IO带宽，fsync()会被阻塞，进而阻塞整个事件循环——所有客户端请求、复制命令发送都会卡住。
-
no-appendfsync-on-rewrite yes：重写期间主进程跳过fsync()，只把AOF缓冲区内容写入内核页缓存，由系统决定何时落盘 - 副作用是故障时最多丢失30秒数据（Linux默认
vm.dirty_expire_centisecs = 3000），但比同步卡死强得多 - 务必配合
appendfsync everysec使用；always模式下此配置无效
避免高峰期触发AOF重写
AOF重写不是定时任务，而是由auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个条件共同触发。如果业务写入量波动大，高峰时段容易连续触发重写，形成恶性循环。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调高
auto-aof-rewrite-percentage（比如从100改成200），降低触发频率 - 增大
auto-aof-rewrite-min-size（比如从64mb设为256mb），避免小AOF文件频繁重写 - 用
crontab在凌晨低峰期主动执行redis-cli -p 6379 bgrewriteaof，比被动触发更可控 - 监控
redis-cli info persistence | grep aof_last_rewrite_time_sec，确认重写耗时是否异常
主从同步本身不依赖AOF文件
这点常被误解：从节点同步靠的是主节点的复制流（replication stream），不是读取主节点的AOF文件。所以即使关掉AOF，只要RDB+增量命令流正常，主从同步照样工作。AOF只影响主节点本地持久化行为，间接通过资源争抢影响同步效率。
真正影响同步延迟的是网络带宽、主节点CPU/IO负载、复制缓冲区大小（repl-backlog-size）、以及是否发生全量重同步（psync失败后退化为sync）。AOF重写只是其中一环，但它最容易被观测到、也最容易干预。
别为了“数据安全”盲目开AOF然后硬扛延迟——先看业务能否接受30秒内数据丢失，再决定要不要开no-appendfsync-on-rewrite，或者干脆用RDB+从库备份替代AOF。
