首要排查项是repl-timeout，默认60秒，主从间REPLCONF ACK延迟超时即断连；需主从同时调大该值，如设为120秒，并排查TCP保活、输出缓冲区、系统连接限制及ACK抖动等隐性瓶颈。
主从连接频繁断开，repl-timeout 是首要排查项
Redis 主从频繁断开重连，大概率不是网络彻底中断，而是心跳超时被主动断开。默认 repl-timeout 是 60 秒，只要主从之间一次 REPLCONF ACK 延迟超过这个值，从节点就会主动断连并尝试重同步。
高延迟网络（比如跨城、跨云厂商、带宽受限）下，60 秒太紧——尤其在大流量写入或从节点磁盘慢（导致 repl-backlog 积压、ACK 滞后）时，很容易触发。
-
repl-timeout控制的是「主从心跳确认」的等待上限，不是数据传输超时，也不是命令执行超时 - 它只影响
REPLCONF ACK往返，不控制PSYNC或全量 RDB 传输过程 - 修改后需在主从两端都生效：主节点要能接受更长的 ACK 延迟，从节点也要愿意等更久才断
- 建议先观察实际
REPLCONF ACK延迟：用redis-cli -h info replication | grep "master_repl_offset\|slave_repl_offset"对比偏移差，再结合ping和redis-cli --latency -h判断基线延迟
怎么安全调大 repl-timeout？别只改从节点
只在从节点改 repl-timeout 没用，主节点会按自己的配置判断“从节点是否失联”。必须主从同时调整，且主节点优先。
- 主节点配置中设置：
repl-timeout 120（单位秒），然后CONFIG REWRITE或重启生效 - 从节点同样设为
repl-timeout 120，否则它可能等不及就断开，而主节点还没判定失联 - 不要设得过大（比如 300+）：会导致真实故障时发现滞后，故障窗口拉长
- 如果使用 Redis 6.2+，可配合
repl-diskless-sync-delay避免全量同步卡住 ACK，但该参数仅影响 diskless 场景，非必需
repl-timeout 调大后仍断连？检查这些隐性瓶颈
调了 repl-timeout 还断，说明问题不在心跳超时本身，而是底层链路或资源卡点让 ACK 根本发不出/收不到。
- 主节点
tcp-keepalive过短（默认 300 秒），NAT 或中间设备清空连接表，表现为无日志断连——建议设为60（秒） - 从节点
client-output-buffer-limit slave触发强制断连：大 key 或阻塞命令导致输出缓冲区溢出，错误日志含"Client id=xxx addr=xxx:xxx fd=xxx name=replica idle=xxx seconds" "output buffer too large" - 系统级限制：如
/proc/sys/net/ipv4/tcp_fin_timeout过短、TIME_WAIT 连接堆积，或防火墙主动回收长连接 - 主节点 CPU 或磁盘 I/O 饱和，导致无法及时处理
REPLCONF ACK请求，INFO commandstats中replconf的calls和usec_per_call会明显升高
为什么不能依赖 repl-ping-slave-period 来缓解？
repl-ping-slave-period 控制主节点向从节点发 PING 的间隔（默认 10 秒），但它和断连逻辑无关——主节点从不因没收到 PONG 就断从节点。真正起作用的是从节点发来的 REPLCONF ACK 是否超时。
-
repl-ping-slave-period只影响主节点的心跳探测频率，不影响任何超时判定 - 调小它（比如设成 5）只会增加无意义网络包，不解决 ACK 延迟问题
- 误以为它是“保活开关”是常见误解，日志里也看不到相关拒绝记录
- 真正决定断连时机的，始终只有
repl-timeout+REPLCONF ACK时间戳
真正麻烦的是 ACK 延迟不稳：有时 80ms，有时 3 秒，有时直接卡住 20 秒。这种抖动比稳定高延迟更难调参，得靠抓包看 TCP 重传、查网卡丢包、确认中间代理是否做连接复用或限速——repl-timeout 只是最后一道闸门，不是根治手段。
