确认client-output-buffer-limit溢出导致中断需三步验证：CLIENT LIST查omem是否长期＞60MB、日志grep“output buffer”看是否有“Client closed connection due to output buffer limit”、INFO clients观察client_longest_output_list是否持续＞0；参数应按RDB大小与带宽计算，如1.8GB RDB配15MB/s带宽设为"slave 5400mb 2700mb 135"，并同步CONFIG REWRITE。
主从复制中断八成是 client-output-buffer-limit 触发的强制断连，不是网络不稳，也不是 Redis 崩了——是主节点主动把从节点踢了。
怎么确认真是 client-output-buffer-limit 溢出导致的中断
别急着改配置，先看证据：
- 在主节点执行
redis-cli CLIENT LIST，找对应从节点那行，盯住omem字段：如果长期 > 60MB、反复逼近你设的硬限（比如 256MB），基本坐实 - 查主节点日志：
grep "output buffer" /var/log/redis/redis-server.log，出现Client output buffer limit reached或Client closed connection due to output buffer limit就是它 - 运行
redis-cli info clients，看client_longest_output_list是否持续 > 0；这个值高，说明输出队列真在积压 -
qbuf是输入缓冲区，和断连无关；omem才是关键
client-output-buffer-limit slave 三个参数怎么设才安全
默认值 slave 256mb 64mb 60 在中高负载下极易触发断连。调参不能拍脑袋，得按链路算：
- 硬限制（第一个值）建议为 RDB 文件大小 × 2：比如 RDB 稳定在 1.8GB，就设
5400mb - 软限制（第二个值）建议为 RDB 大小 × 1.5：同上例，设
2700mb - 软限持续时间（第三个值）必须 ≥ RDB 传输耗时 × 1.125：1.8GB 在 15MB/s 带宽下需约 120 秒，所以设
135 - 最终命令：
CONFIG SET client-output-buffer-limit "slave 5400mb 2700mb 135" - ⚠️ 必须立刻执行
CONFIG REWRITE，否则重启后回落默认值
只调 client-output-buffer-limit 还不够，必须配对改 repl-backlog-size
这两项是绑定生效的，单改一个等于白干：
-
repl-backlog-size决定从节点断连后能“追多远”；默认仅 1MB，高压下重连必退化全量同步，又压回client-output-buffer-limit的坑 - 建议设为
1073741824（1GB），至少不低于client-output-buffer-limit软限的 1/2 - 同步执行：
CONFIG SET repl-backlog-size 1073741824，再CONFIG REWRITE - 如果从节点网络延迟波动大（比如跨可用区），还得调大
repl-timeout至 120–300，否则心跳超时比缓冲区溢出还早断连
容易被忽略的细节：每个从节点独占一份缓冲区
5 个从节点同时拉 RDB，主节点就要维护 5 份独立的输出缓冲区。调参前必须确认：
- 当前有多少个从节点（
redis-cli info replication看connected_slaves） - 它们是否部署在同一机房：跨公网或跨可用区时，
omem积累速度远高于同机房，光调 buffer 治标不治本 - 是否启用了
repl-diskless-sync yes：避免主节点先写磁盘再读取发送，能显著降低缓冲区压力 -
client-output-buffer-limit的slave类型只影响主从同步连接，pubsub和normal类型不用动，除非你明确看到对应连接的omem异常高
