主从频繁断开八成是client-output-buffer-limit slave触发强制断连；确认方法：查client list中omem是否长期＞60mb、日志是否有“output buffer limit”报错、info clients中client_longest_output_list是否持续＞0；安全调参需按rdb大小和带宽计算，如1.8gb rdb配15mb/s带宽应设为"slave 5400mb 2700mb 135"，并同步写入redis.conf。
主从频繁断开，八成是 client-output-buffer-limit slave 触发了强制断连，不是网络不稳，也不是配置写错了——是主节点主动把从节点踢了。
怎么确认真是 output buffer 导致的断连
别一上来就改配置，先验证是不是它在作祟：
- 在主节点执行
CLIENT LIST，找从节点那行，盯住omem字段：如果长期 > 60MB，甚至逼近 64MB，基本就是它 - 查主节点日志：
grep "output buffer" /var/log/redis/redis-server.log，看到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 0 0 0"（禁用限制），多从节点时容易把主节点内存撑爆。得按实际链路来配：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB 文件大小约 1.8GB、从节点上行带宽稳定在 15MB/s → 传输至少需 120 秒 →
time参数必须 ≥ 135 - 软限制（第二个值）建议为 RDB 大小 × 1.5，比如 1.8GB → 设为
2700mb - 硬限制（第一个值）设为软限 × 2，即
5400mb - 最终命令：
CONFIG SET client-output-buffer-limit "slave 5400mb 2700mb 135"
⚠️ 必须同步写入 redis.conf 并执行 CONFIG REWRITE，否则重启后回落默认值 "slave 256mb 64mb 60"。
比调参更关键的三件事
参数只是兜底，治标不治本：
- 启用
repl-diskless-sync yes：避免主节点先写磁盘再读取发送，直接 socket 发送 RDB，大幅降低缓冲区积压风险 - 检查
repl-timeout：默认 60 秒太敏感，高延迟网络下建议调到 120–180；否则哪怕缓冲区没满，心跳超时也会断连 - 确认从节点与主节点是否同机房：跨可用区或公网同步时，延迟波动大、丢包率高，
omem极易堆积；这种场景下光调 buffer 没用，得先收敛网络路径
真正容易被忽略的是：omem 是每个从节点独立计算的。5 个从节点同时拉 RDB，主节点就要维护 5 份输出缓冲区——调参前务必确认从节点数量和部署拓扑。
