Redis主节点bgsave导致从节点数据落后，根本原因是fork()阻塞主线程，使replication buffer断流；当RSS达16GB、latest_fork_usec超1s、内存碎片率高时，复制偏移量停滞甚至触发全量同步。
Redis从节点数据落后主节点，往往不是网络或从节点慢，而是主节点在执行 bgsave 时被严重拖累——尤其当主库内存大、碎片高、写入快时，bgsave 的 fork() 阻塞会直接卡住复制命令的生成和发送。
为什么 bgsave 会让主节点“发不出”同步数据
主节点不是把数据实时推给从节点，而是先把写命令缓存在内存里的 replication buffer（复制缓冲区），再异步发出去。一旦 bgsave 触发，fork() 过程会阻塞整个 Redis 主进程：
-
fork()耗时与主进程 RSS 内存大小强相关：16GB RSS 可能导致latest_fork_usec达到 1s 级别 - 阻塞期间，所有新写命令无法追加进
replication buffer，缓冲区“断流” - 从节点收不到新命令，偏移量（
master_repl_offset）停滞，表现为“数据落后几个 GB” - 若此时缓冲区已满（默认 1GB），还会触发全量重同步，进一步加剧延迟
怎么确认是 bgsave 导致的复制延迟
别只看 INFO replication 里的 slave0:offset=xxx 差值，重点查三个指标：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
INFO stats，观察latest_fork_usec：若周期性出现 >500000（即 500ms），基本锁定fork问题 - 执行
INFO memory，对比used_memory_rss_human和used_memory_human：差值 > 2GB 说明内存碎片严重，fork开销会指数级上升 - 执行
redis-cli --stat，看instantaneous_output_kbps是否在bgsave时段骤降甚至归零
bgsave 配置和替代方案的实际取舍
关掉 bgsave 是最快止血方式，但不可长期使用——RDB 是故障恢复最可靠的兜底手段。更稳妥的做法是分离职责：
- 主节点禁用
bgsave（save ""），专注读写和复制，避免任何fork风险 - 选一台从节点开启
bgsave（确保它不承担线上读流量），专门做持久化 - 该从节点需配置足够大的
repl-backlog-size（如2gb），防止主从短暂断连后被迫全量同步 - 若必须保留主节点 RDB，可改用
redis-cli --rdb手动触发（避开高峰期），或升级到 Redis 7+ 启用copy-on-write优化的fork改进
容易被忽略的底层细节
很多人以为只要内存够、CPU 满就没事，但 fork() 性能其实极度依赖操作系统页表效率。RSS 16GB 不代表用了 16GB 数据，可能是 8GB 数据 + 8GB 碎片；而页表大小可能达 30MB 以上，fork 就是在拷贝这张表。即使你开了 activedefrag yes，它只对后续写生效，对已存在的大碎片无感——迁移实例或重启才是唯一根治法。
