Redis主从频繁断开八成是client-output-buffer-limit slave触发强制断连；查主节点日志含“output buffer limit”报错、CLIENT LIST中omem长期>60MB、info clients中client_longest_output_list持续>0即可确认。
查主节点日志里有没有“output buffer limit”报错
主从频繁断开，八成不是网络抖动，而是主节点主动踢掉从节点——触发条件就是 client-output-buffer-limit slave 限制被突破。先别改配置，直接验证：在主节点执行 grep "output buffer" /var/log/redis/redis-server.log。如果看到 Client closed connection due to output buffer limit，就坐实了。这个错误说明主节点的输出缓冲区（omem）长期超限，不是瞬时峰值，是持续积压。
用CLIENT LIST看从节点omem是否长期 >60MB
omem 是每个从节点独立维护的输出缓冲区大小，单位字节。在主节点执行 redis-cli CLIENT LIST，找到对应从节点那一行，盯住 omem 字段：
- 如果长期稳定在 60MB–64MB 之间，甚至反复打到 67108864（即 64MB），基本就是它
-
qbuf是输入缓冲区，和断连无关，别被它带偏 - 注意：5 个从节点同时拉 RDB，主节点就要撑 5 份
omem，拓扑没理清就调参等于埋雷
检查repl-timeout和repl-ping-slave-period是否倒挂
即使 omem 没爆，心跳超时也会强制断连。两个参数必须满足： repl-timeout ≥ repl-ping-slave-period × 5。默认值是 repl-timeout 60、repl-ping-slave-period 10，看似合理，但实际中：
- 跨可用区或公网同步时，网络延迟波动大，10 秒 ping 一次太激进
- 主节点执行慢查询（如
keys *、hgetall bigkey）期间无法响应 ACK，repl-timeout很容易被耗尽 - 建议生产环境设为
repl-timeout 180、repl-ping-slave-period 30，并写入redis.conf
确认是否真在走增量复制而非反复全量同步
如果从节点断线后每次重连都拉完整 RDB，说明复制积压缓冲区（repl-backlog-size）太小，导致 offset 被覆盖。验证方法：
- 在主节点执行
info replication，看repl_backlog_active是否为 1、repl_backlog_size是否明显小于当前 RDB 大小 - 计算公式：最优
repl-backlog-size= 2 × 预估断线恢复时间（秒） × 主节点平均每秒写入字节数 - 比如平均写入 2MB/s、预计最长断线 90 秒，则设为
repl-backlog-size 360000000（约 360MB）
client-output-buffer-limit、repl-backlog-size、repl-timeout）都必须写进 redis.conf 并执行 CONFIG REWRITE，否则重启后立刻回落默认值。 
