主节点因输出缓冲区超限（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，形成恶性循环——所以得同时处理“主节点缓冲区策略”和“从节点加载效率”两个面，单点优化很难破局。