90%以上Redis主从频繁断连是默认参数在抖动、慢同步或缓冲区压力下集体失效所致；排查须依次验证日志配置（logfile+loglevel）、repl-timeout（建议≥bgsave最大耗时2倍）、client-output-buffer-limit slave（按写入速率×超时计算）、Linux内核tcp_keepalive_time（建议调至300秒）及repl-backlog-size（跨机房≥512MB）。
直接结论：90%以上的Redis主从频繁断连，不是网络真断了，而是默认参数在抖动、慢同步或缓冲区压力下集体失效。排查必须从日志、超时、缓冲区、内核四层往下压，不能只盯着“连不上”本身。
从节点日志为空？先确认logfile是否真正生效
很多排查卡在第一步：你根本没看到任何错误。因为redis.conf里logfile默认是空字符串，等于日志完全关闭。运行redis-cli CONFIG GET logfile，如果返回""，说明所有日志都丢了。
- 必须同时设置
logfile /var/log/redis/redis-server.log和loglevel notice（调试时可临时设为verbose） - 只改
loglevel不设logfile，等于调高音量却关掉喇叭 - 验证方式：
tail -f /var/log/redis/redis-server.log，启动从节点后几秒内必须滚动出Connecting to MASTER或MASTER aborted replication类日志
repl-timeout太小导致心跳误判断连
主节点靠repl-timeout判断从节点是否存活，默认60秒。但心跳实际每repl-timeout / 2秒发一次（即30秒），中间只要出现一次TCP重传延迟、BGSAVE卡顿、或从节点CPU打满无法及时读取socket，就可能错过心跳窗口，触发Disconnecting timedout replica。
- 高频写入+大RDB场景下，
bgsave耗时很容易超过60秒，从节点等不到数据就主动断开 - 紧急修复无需重启：
CONFIG SET repl-timeout 300（建议值：至少是预估bgsave最大耗时的2倍） - 别只调这个——如果
repl-ping-slave-period（默认10秒）和repl-timeout接近，网络丢一个PING就容易误判
client-output-buffer-limit slave被撑爆强制断开
这是最隐蔽也最常被忽略的断连原因。主节点会为每个从节点维护一个输出缓冲区，用于暂存增量命令。一旦缓冲区溢出，主节点会立刻KILL该连接，日志里只显示Connection with master lost，没有明确提示缓冲区问题。
- 典型表现：主节点
INFO clients中client_longest_output_list持续很高，或INFO replication里slave0状态反复变up/down - 紧急修复：
CONFIG SET client-output-buffer-limit "slave 1024mb 512mb 120"（单位MB，第三个数字是秒数） - 计算依据：缓冲区容量 ≥ 峰值写入速率 ×
repl-timeout；例如写入10MB/s、repl-timeout=300，至少要预留3GB
Linux内核TCP保活未配合，让断连感知延迟过长
Redis自己的tcp-keepalive默认300秒，而Linux内核默认tcp_keepalive_time是7200秒。这意味着即使物理链路已断，应用层要等几分钟才感知到，期间复制积压缓冲区（repl-backlog-size）早被覆盖，重连只能全量同步。
- 必须同步调低内核参数：
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time（并写入/etc/sysctl.conf持久化） -
repl-backlog-size也要放大，否则抖动恢复后无法部分重同步；跨机房建议≥512MB（公式：写入峰值 × 断连容忍窗口） - 注意：
tcp-keepalive设太小（如30秒）可能引发大量无效探测，300秒是生产环境较稳妥的平衡点
真正难处理的从来不是单点参数，而是参数之间的耦合关系：比如调大repl-timeout却不调大repl-backlog-size，抖动一长照样全量同步；调大缓冲区却不改内核tcp_keepalive_time，断连感知还是慢半拍。所有参数必须按链路瓶颈协同调整，而不是孤立修改。
