根本原因是fork()阻塞主线程导致replication buffer断流；当latest_fork_usec＞500000、RSS达16GB或内存碎片率高时，新写命令无法入缓冲区，master_repl_offset停滞，从节点数据滞后数GB。
为什么主库高频bgsave会导致复制偏移量停滞
根本原因不是“写入慢”，而是fork()阻塞主线程，让replication buffer断流。主节点不直接推命令给从节点，而是先追加到内存缓冲区，再异步发送。一旦fork()卡住主线程（比如latest_fork_usec > 500000），新写命令就无法进缓冲区——从节点收不到任何增量，master_repl_offset长时间不动，表现为“落后几个 GB”。
-
fork()耗时与主进程 RSS 内存强相关：16GB RSS 常见 1s 级延迟，35GB 可能超 200ms - 内存碎片率高（
used_memory_rss_human - used_memory_human > 2GB）会让fork()开销指数级上升 - 高频触发（如
save 60 10000）等于每分钟强制卡主线程一次，抖动不可控
高频bgsave对SUBSCRIBE客户端的隐性影响
发布/订阅不走命令队列，但消息推送依赖主线程调度和底层资源。当bgsave执行时，fork()阻塞 + 子进程 COW 拷页 + 磁盘 write 压力，三者叠加会拖慢内核网络栈。典型表现是 SUBSCRIBE 客户端 READ 系统调用延迟升高，消息“卡顿”而非“丢失”。
- 用
perf record -e syscalls:sys_enter_write -p <redis-pid>常能抓到个别write耗时 >50ms -
iostat -x 1中await持续 >10ms 或%util>80% 是磁盘瓶颈信号 - 即使没报错，
redis-cli --stat里instantaneous_output_kbps在bgsave时段归零，说明主线程已失能
主库禁用自动bgsave后，全量同步还能工作吗
能，但必须满足两个前提：repl-diskless-sync yes + 主节点有权限生成 RDB 流。首次全量同步仍需触发bgsave，只是目的变了：不再写磁盘文件，而是 fork 出子进程，把内存数据序列化后直接写进 socket 缓冲区。如果主节点配置了save ""且磁盘路径可写，这个流程照常进行；但如果dir不可写或dbfilename权限不足，就会卡在WAIT_BGSAVE_START并报Failed to create RDB file。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查
INFO persistence中的rdb_bgsave_in_progress是否为 1，确认子进程真正在跑 -
repl-diskless-sync yes不跳过bgsave，只跳过磁盘落盘环节 - 禁用
save规则后，务必保留appendonly yes和aof-use-rdb-preamble yes作为兜底
真正绕过fork阻塞的生产实践
靠调参或改save间隔解决不了问题，因为fork()本身是同步系统调用，无法被 Redis 规避。唯一稳定路径是职责分离：主节点彻底不碰fork，所有持久化压力转移到从节点或外部工具。
- 主节点配置
save ""+appendonly yes+aof-use-rdb-preamble yes - 选一台专用从节点开启
save 300 500，并配repl-backlog-size 2gb防断连重同步 - 禁用 THP：
echo never > /sys/kernel/mm/transparent_hugepage/enabled（需重启 Redis 生效） - 单实例内存建议 ≤16GB；超大容量必须分片，硬扛只会让
latest_fork_usec越来越不可控
关键点在于：bgsave的“后台”仅指写文件阶段，fork()那一瞬间永远在主线程里同步完成——这个事实容易被日志里的“Background saving started”误导。
