主节点因bgsave阻塞导致从节点断连，本质是fork+RDB写入期间复制流中断；确认方法包括查日志耗时、INFO persistence中rdb_bgsave_in_progress状态、redis-cli --stat流量骤降；解法为启用repl-diskless-sync yes并同步调大client-output-buffer-limit与repl-timeout，同时确保vm.overcommit_memory=1、repl-backlog-size足够、SELinux不拦截socket。
主节点因持久化慢导致从节点断连，本质是 bgsave 阻塞了复制流发送——不是网络问题，也不是认证失败，而是主节点在 fork + 写 RDB 过程中无法及时向从节点推送数据，触发 repl-timeout 或压爆 client-output-buffer-limit。
怎么看是不是 bgsave 拖垮了同步
别急着调参，先确认瓶颈位置：
- 查主节点日志：grep "Background saving started" 和紧随其后的 "Background saving terminated" 时间差，若单次
bgsave耗时 > 30 秒（尤其 >repl-timeout），就是罪魁祸首 - 执行
INFO persistence，看rdb_bgsave_in_progress是否长期为 1，同时master_repl_offset在INFO replication中几乎不动 - 用
redis-cli --stat观察in=流量是否在bgsave期间骤降甚至归零——说明主节点卡在 IO 上，没空发命令
禁用 RDB 磁盘落盘是最直接的解法
启用无盘同步后，主节点不再写本地 RDB 文件，而是 fork 后直接把内存数据流式发给从节点，绕过磁盘 IO 瓶颈：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须设
repl-diskless-sync yes，否则默认仍走磁盘路径 - 搭配
repl-diskless-sync-delay 5（可选）：允许多个从节点等待 5 秒内一起接入，减少重复 fork 开销 - 注意前提：从节点内存要够大，能一次性接收完整 RDB 流；若 RDB > 2GB 且从节点内存紧张，慎用
必须同步调整的两个关键参数
无盘同步只是绕开磁盘，但数据量大、网络慢时，输出缓冲区仍会积压。以下两项必须一起改，缺一不可：
-
CONFIG SET client-output-buffer-limit "slave 4096mb 2048mb 180"：硬限 4GB、软限 2GB、超时 180 秒。值按 RDB 大小 × 1.5（软限）和带宽估算（如 1.5GB RDB / 10MB/s → 至少需 150 秒传输） -
CONFIG SET repl-timeout 180：默认 60 秒太敏感，bgsave或网络抖动时极易误判断连；设为缓冲区超时时间的 1–1.2 倍更稳妥
真正容易被忽略的细节
很多人调完 repl-diskless-sync 就以为万事大吉，但实际还有三个隐性雷：
-
repl-backlog-size必须同步放大——无盘同步不改变增量命令的堆积逻辑，高压下积压仍可能冲垮 backlog - 主节点
vm.overcommit_memory必须为 1：否则 fork 失败，bgsave直接报错，从节点连握手都进不去 - SELinux 或防火墙若拦截了 socket 传递（非传统 TCP 连接），会导致无盘同步静默失败，日志里只显示 “Connection refused” 或空连接
