主节点因输出缓冲区超限（client-output-buffer-limit slave 256mb 64mb 60）主动断开从节点连接，表现为日志出现“Client closed connection due to output buffer limit”，INFO replication中状态在connect→sync→disconnected循环；确认需查CLIENT LIST的omem字段、日志关键词及INFO clients的client_longest_output_list；调参须匹配RDB大小与带宽，如2GB RDB配“slave 6gb 3gb 120”，并启用repl-diskless-sync等链路优化。
从节点加载 RDB 过慢本身不会导致主库断开连接；真正触发断连的是主节点因输出缓冲区积压超限，主动 kill 掉从节点连接。 这个过程常被误认为“加载慢 → 断连”，但本质是主节点的 client-output-buffer-limit 策略在起作用。
为什么主节点会主动断开从节点连接
主节点对每个 slave 客户端强制设置了输出缓冲区上限，默认值是 client-output-buffer-limit slave 256mb 64mb 60。意思是：
- 硬限制：缓冲区占用超过 256MB，立即断连
- 软限制：连续 60 秒内缓冲区持续 ≥ 64MB，也断连
- 这个缓冲区存的是“还没发给从节点的 RDB 数据”——不是从节点在解析，而是主节点在等从节点 ACK 或网络太慢，数据卡在主节点内存里
典型现象是主节点日志出现 Client closed connection due to output buffer limit，且 INFO replication 中从节点状态在 connect → sync → disconnected 循环。
如何确认确实是 output buffer 触发的断连
别急着改配置，先验证是不是它：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在主节点执行
CLIENT LIST，找对应从节点那一行，重点看omem字段（不是qbuf）是否长期 ≥ 60MB - 查主节点日志：
grep "output buffer\|client closed" /var/log/redis/redis-server.log - 执行
INFO clients，观察client_longest_output_list是否长期 > 0
如果三项都符合，基本锁定问题根源。
调整 client-output-buffer-limit 的实操要点
调参不是越大越好，得匹配实际传输能力：
- RDB 文件大小为 2GB、从节点上行带宽稳定 20MB/s → 传输理论耗时约 100 秒 →
time参数至少设为120 - 软限制（第二个值）建议为 RDB 大小的 1.5 倍，比如
3gb；硬限制（第一个值）可设为软限的 2 倍，如6gb - 生效命令：
CONFIG SET client-output-buffer-limit "slave 6gb 3gb 120" - ⚠️ 必须同步写入
redis.conf，否则重启后恢复默认值 - ⚠️ 多从节点并发同步时，每个从节点的
omem独立计算，总内存压力 = 单节点上限 × 从节点数
比调参更关键的三件事
参数只是兜底，治本要从链路优化入手：
- 启用
repl-diskless-sync yes：主节点不再把 RDB 写磁盘再读取发送，而是 fork 后直接通过 socket 发送，大幅减少输出缓冲区积压机会 - 清理从节点本地残留文件：启动前删掉旧的
dump.rdb和appendonly.aof，避免从节点启动时主线程卡在本地磁盘读取（这阶段完全不走rdb-loading-threaded） - 开启 RDB 多线程加载（仅对从节点全量同步阶段有效）：
rdb-loading-threaded yes+io-threads 2（注意：设io-threads 1无效，必须 ≥2）
真正容易被忽略的是：RDB 加载慢 ≠ 主节点断连原因；而主节点断连后，从节点重试又拉取大 RDB，形成恶性循环——所以得同时处理“主节点缓冲区策略”和“从节点加载效率”两个面，单点优化很难破局。
