根本原因是每个直连从库全量同步时均触发独立fork，而fork需拷贝内存页表，在大内存、高碎片下耗时数秒，导致主库CPU飙升和延迟激增；解决方式是采用级联复制，将fork压力集中到中继节点，使主库fork次数从N次降至1次。
主库压力过大，根本原因不是“同步太多”，而是每个从库直连主库时都触发独立的 fork 子进程生成 RDB——这个动作在内存大、碎片高时会卡顿甚至失败。解决思路不是压低同步频率，而是让部分从库不直连主库。
为什么 fork 是主库 CPU 和延迟飙升的元凶
全量同步必须走 RDB 快照，而 Redis 主节点每次生成快照都要 fork 一个子进程。这个操作拷贝的是当前进程的页表（Copy-on-Write），不是实际数据大小。即使你只存了 200MB 数据，但 Redis 占用 6GB 内存且 mem_fragmentation_ratio > 1.8，fork 就可能耗时 3～5 秒，期间主库命令延迟明显上升，INFO stats 中 latest_fork_usec 会飙到几十万微秒。
更麻烦的是：每个直连的从库发起全量同步，都会触发一次独立 fork。5 个从库同时重连？主库大概率连续 fork 5 次，CPU 利用率冲到 95%+，rdb_bgsave_in_progress 长时间为 1，写入抖动剧烈。
用级联复制把 fork 压力转移到中间层从库
让一部分从库（比如 3 个）不连主库，改连另一个从库（称为“中继节点”），这样只有中继节点需要向主库做全量同步，其余节点从中继节点拉取数据——主库的 fork 次数从 N 次降到 1 次。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 中继节点必须开启
replica-serve-stale-data yes（旧版叫slave-serve-stale-data），否则它拒绝服务读请求，无法充当上游 - 中继节点要显式配置
replica-announce-ip和replica-announce-port，否则下游孙节点连不上它（默认它广播的是自己监听的 IP，不是对外可访问地址） - 孙节点配置只需一行：
SLAVEOF 10.0.1.22 6379（指向中继节点 IP 和端口） - 禁用
replica-read-only no不必要，默认yes已足够安全
repl-diskless-sync 能缓解但不能替代级联
开启 repl-diskless-sync yes 可跳过磁盘写 RDB，直接 socket 发送流式快照，确实能减少 I/O 压力。但它没减少 fork 次数，也没降低内存页表拷贝开销。实测中，5 个直连从库 + diskless 同步，主库 fork 延迟依然叠加；换成 1 主 → 1 中继 → 4 孙，主库 fork 压力下降 80% 以上。
注意：repl-diskless-sync-delay 控制等待更多从库加入本次快照传输的时间窗口（默认 5 秒），设太大会拖慢单个从库同步启动，设太小则起不到聚合效果。生产建议保持默认或调至 3 秒。
别忽略 repl-backlog-size 对级联稳定的影响
级联结构下，中继节点既是下游的主库，又是上游的从库。它的 repl-backlog-size 必须足够大（建议 ≥512MB），否则当中继节点短暂断连后重连，因积压缓冲区不足触发全量同步，它自己又要 fork —— 这次 fork 虽然不发生在主库，但会导致整条链路中断几秒，所有孙节点跟着卡住。
检查方式：redis-cli -p 6379 INFO replication | grep backlog，确认 repl_backlog_active 为 1 且 repl_backlog_size 符合预期。低于 128MB 的值在中等写入量下极易溢出。
