慢从库会撑爆缓冲
主库为每个从库维护一份输出缓冲区，暂存已经生成但还没发出去的复制流。从库处理慢或链路带宽不足时缓冲会持续堆积，一旦突破限制，主库会主动断开这个从库。断连重连往往意味着一轮全量同步，负载进一步抬高，容易形成反复掉线的循环。
基本信息
| 配置项 | 客户端输出缓冲限制，其中复制类单独一组阈值 |
|---|---|
| 默认值 | 复制类为 256mb 硬限制、64mb 软限制、60 秒 |
| 语义 | 硬限制是瞬时上限；软限制需持续超限指定秒数才触发 |
| 相关项 | 复制积压缓冲大小影响断连后能否做部分重同步 |
典型使用场景
- 从库周期性掉线：主库日志提示输出缓冲超限
- 主库内存异常上涨：缓冲堆积直接占用主库内存
- 大写入之后从库长时间落后：链路带宽跟不上写入流量
- 放大限制后仍然复发：说明根因在从库处理能力或网络带宽
查看与调整
查看与调整
redis-cli CONFIG GET client-output-buffer-limit # 查看各类客户端的限制
redis-cli CONFIG SET client-output-buffer-limit "replica 512mb 128mb 60" # 按需放大
redis-cli INFO clients | grep -E 'client_longest_output_list|client_biggest_input_buf'
redis-cli CLIENT LIST TYPE replica | grep -E 'omem|obl' # 逐个从库看输出缓冲占用
redis-cli INFO stats | grep -E 'sync_full|sync_partial_ok|sync_partial_err'
redis-cli INFO replication | grep lag信号解读
| 信号 | 含义 | 处置思路 |
|---|---|---|
| 连接输出缓冲占用 | 该连接缓冲占用的内存 | 从库连接上持续增长即为堆积 |
| 最长输出队列 | 客户端输出队列长度峰值 | 明显偏大说明有客户端消费不过来 |
| 全量同步次数增长 | 断连后无法部分重同步 | 查积压缓冲大小与网络质量 |
| 部分重同步失败次数 | 跳过全量同步的尝试失败 | 多为积压缓冲不足或断连时间过长 |
| 硬限制触发 | 缓冲瞬时超限，立即断开 | 结合从库处理能力评估 |
| 软限制触发 | 长时间超限后断开 | 通常是持续性带宽或处理瓶颈 |
定位顺序建议：先看主库日志里的断开原因是否提到输出缓冲，再看客户端列表里该从库连接的缓冲占用，最后对照从库的 CPU、磁盘与网络带宽，判断瓶颈在发送侧还是接收侧。
复制积压缓冲决定从库短时断连能否做部分重同步。缓冲太小时每次抖动都会退化成全量同步，写入量大的实例应适当上调，并观察全量同步计数是否回落。
把限制设成 0 等于取消上限：一个卡住的从库可能把主库内存吃光，最终触发内存不足。生产上更稳妥的做法是保留硬限制，同时定位并解决从库慢的根因。