主库频繁fork的本质是因repl-backlog-size过小或从库断连过多，导致PSYNC失败而反复触发bgsave全量同步；应按“峰值写入速率×断连容忍时间”科学扩容backlog，并监控latest_fork_usec＞100000及时干预。
主库频繁执行同步，本质是频繁触发 bgsave + fork，不是“同步太勤”，而是“从库重连太多”或“积压缓冲区太小”逼得主库反复全量重传。核心要砍掉不必要的全量同步，而不是调快同步频率。
为什么主库会频繁 fork？关键看 latest_fork_usec
每次全量同步，主库必须 bgsave，而 bgsave 必须 fork。内存越大、碎片越多，fork 耗时越长——6GB 内存+高碎片时，单次 fork 可卡主线程 3～5 秒。5 个从库同时断连，就是连续 5 次 fork，CPU 和延迟直接崩。
监控唯一真实指标：INFO stats 中的 latest_fork_usec。如果它持续 >100000（即 >100ms），说明 fork 已成瓶颈，必须干预。
- 别只盯着
connected_slaves数量，要看slave_repl_offset是否频繁归零或跳变 -
master_last_io_seconds_ago若长期 >60，说明从库网络不稳，极易触发重同步 - 查日志里有没有大量
Connection with slave X.X.X.X:XXXX lost
repl-backlog-size 设太小，等于主动制造全量同步
从库断连后重连，能否走增量同步（PSYNC），全看 repl_backlog_buffer 里还剩多少命令。设得太小，断连几秒就溢出，只能全量重来。
别用默认的 1MB。按写入峰值和容忍断连时间算：
- 写入峰值 20 MB/s，允许断连最长 60 秒 → 至少要
repl-backlog-size 1200mb（再加 1.5 倍安全余量） - 小型实例（内存 ≤4GB，QPS 128mb，别省
- 务必配
repl-backlog-ttl 0，避免空闲时缓冲区被回收
验证是否生效：INFO replication 看 repl_backlog_histlen 是否稳定在高位，而不是总为 0。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用级联复制把 fork 压力甩给中继节点
主库压力大，不是因为从库多，而是每个直连从库都逼它 fork 一次。解决方案不是砍从库，是让部分从库不连主库，改连另一个从库（中继节点）。
- 中继节点必须开
replica-serve-stale-data yes，否则拒绝读请求，无法当上游 - 中继节点必须显式设
replica-announce-ip和replica-announce-port，否则孙节点连不上（它广播的是监听地址，不是可访问地址） - 孙节点只需一行：
SLAVEOF - 主库直连从库建议 ≤3 个，其余全部走中继
效果：主库 fork 次数从 N 次降到 1 次，中继节点承担生成 RDB 的开销，主库只专注业务写入。
repl-diskless-sync 能减 IO，但救不了 fork 延迟
启用 repl-diskless-sync yes 后，主库 fork 出的子进程不再写磁盘 RDB，而是直接 socket 流式发送，对 SSD 寿命和传输耗时有改善。但它不减少 fork 次数，页表拷贝开销仍在。
- 适合磁盘 IO 成瓶颈的场景（如云服务器 EBS）
- 搭配
repl-diskless-sync-delay 3（默认 5），让主库多等几秒，聚合多个等待中的从库一起传输 - 注意：网络不稳定时，流式传输失败会导致重试成本更高，不能替代级联
真正卡主库的从来不是磁盘，而是 fork 本身。所以级联是根治手段，无盘复制只是辅助。
最容易被忽略的点：所有从库必须设 replica-read-only yes（默认值），否则误写会污染数据；另外，禁用主库的 save 策略（save ""），避免手动 SAVE/BGSAVE 与主从同步争抢 fork 资源。
