fork阻塞主线程是Redis持久化延迟的根本原因，因bgsave和bgrewriteaof均需调用fork()，导致主线程完全挂起；阻塞时长取决于内存大小、系统环境及THP设置，大内存实例下可达200–500ms，严重拉高P99延迟。
fork阻塞主线程是根本原因
Redis执行bgsave或bgrewriteaof时，必须调用fork()创建子进程。这个系统调用会**完全阻塞Redis主线程**，直到子进程创建完成——期间所有客户端请求都被挂起，无法处理。这不是Redis自己“慢”，而是操作系统层面的同步等待。
阻塞时长取决于父进程内存大小和系统环境：内存越大，内核需要复制的页表和虚拟地址空间元数据越多；虚拟机环境因内存管理开销更大，fork耗时通常是物理机的2–5倍。
-
info命令返回的latest_fork_usec字段就是上一次fork耗时（单位微秒），超过100ms就已属高风险 - 若实例内存达20GB以上，
fork常达200–500ms，P99延迟直接被拉高一个数量级 - Linux transparent huge pages（THP）启用时，
fork性能进一步恶化，建议禁用：echo never > /sys/kernel/mm/transparent_hugepage/enabled
everysec模式下AOF重写也会触发fork
很多人以为只有bgsave才触发fork，其实bgrewriteaof同样依赖fork——哪怕你只启用了appendfsync everysec，当AOF文件增长到auto-aof-rewrite-percentage阈值时，Redis会自动触发重写，此时仍会卡住主线程。
- AOF重写不是“追加”，而是由子进程读取当前数据库状态，生成一个最小化新AOF文件，因此必须
fork - 即使禁用
bgsave，只要appendonly yes且AOF持续写入，重写就可能随时发生 - 可通过
CONFIG GET auto-aof-rewrite*检查是否启用了自动重写，临时关闭可用CONFIG SET auto-aof-rewrite-percentage 0
主从分离是最直接有效的缓解手段
把持久化任务从主节点剥离，是解决fork影响业务最稳妥的方式。主节点专注读写，从节点承担所有fork型操作，两者数据通过异步复制保持一致。
- 从节点开启
save或appendonly yes后，它的bgsave/bgrewriteaof不会影响主节点响应 - 注意配置
slave-read-only yes防止误写，同时确认repl-diskless-sync no（避免无盘同步加重fork压力） - 若使用Redis 6+，可考虑
replica-serve-stale-data no配合监控，确保从节点不可用时不降级提供脏数据
大内存实例+频繁持久化=延迟雪球效应
当实例内存大、且save规则设置过密（如save 60 10000）时，fork会高频出现。更危险的是，如果恰逢业务高峰，主线程刚从一次fork恢复，又立刻因另一条件触发下一次fork，导致延迟连续叠加。
- 用
redis-cli --latency -h持续观察基线延迟，突增点大概率对应host-pportfork时刻 -
SLOWLOG里看不到bgsave记录，因为它不在命令执行路径中，需结合INFO persistence里的rdb_bgsave_in_progress和aof_rewrite_in_progress判断 - 真正难排查的是“伪稳定”场景：延迟波动不规律、单次
fork不超100ms，但每分钟都来一下，长期压低P99体验
实际部署中，最容易被忽略的是：**你以为关掉了bgsave就万事大吉，却忘了AOF重写仍在后台悄悄fork；你以为上了SSD就能扛住IO，却没意识到fork阻塞发生在内存拷贝阶段，跟磁盘快慢毫无关系。**
