repl-timeout是主节点等待从节点REPLCONF ACK心跳响应的最大时长，非客户端超时或RDB传输超时；默认60秒易致“断开→全量→再超时”死循环，生产推荐设为600秒并同步收紧client-output-buffer-limit、调大repl-backlog-size及启用tcp-keepalive。
repl-timeout 默认 60 秒在多数生产环境已不安全，必须调大，否则会触发“断开 → 全量同步 → 再超时 → 再断开”的死循环。
repl-timeout 是什么，又不是什么
它控制的是主节点等待从节点 REPLCONF ACK 心跳响应的最大时长，不是客户端连接超时，也不是 RDB 传输超时，更不等于网络 RTT。主节点每收到一次 ACK 就重置计时器；一旦超过该值未收到，立刻 Disconnecting timedout replica 并关闭连接。日志里反复出现这句，基本可锁定是它在作祟。
常见误操作包括：
– 把 timeout（客户端空闲断连）和 repl-timeout 混用
– 在云环境（如阿里云、AWS）下忽略中间设备的 idle timeout（常为 300~900 秒），只调 repl-timeout 却不管 tcp-keepalive
– 认为设成 0 就能“永不超时”，结果异常连接长期滞留，耗尽 maxclients
为什么 60 秒不够用？真实场景测算逻辑
默认值适合单机或局域网测试，但生产中需覆盖最差同步窗口：网络抖动持续时间 + P99 RTT + 全量同步缓冲期。例如：
- 实测跨机房 P99 RTT 是 45ms → 基础值至少
45 * 3 = 135ms - 主库峰值写入 3MB/s，
repl-backlog-size设为 2GB → 全量同步预估耗时约 4 分钟 - 叠加后保守下限应 ≥
240 + 5 = 245秒，生产推荐直接设为600
验证方式很简单：redis-cli config get repl-timeout 查当前值，再结合 redis-cli -h <master> ping</master> 和 ping -c 10 <master-ip></master-ip> 看 P99 RTT。若前者是 60，后者 >15ms，就已在风险区。
只改 repl-timeout 会失败的三个隐藏点
调大 repl-timeout 是必要条件，但不是充分条件。以下三点任一缺失，照样掉进死循环：
-
client-output-buffer-limit slave未收紧：主节点输出缓冲区会持续堆积，最终触发强制断连。必须同步执行config set client-output-buffer-limit "slave 1024mb 512mb 60"，其中软限（512MB）要 ≥ 主库每秒写入 ×repl-timeout -
repl-backlog-size不够大：若断连期间写入超出 backlog 容量，从节点重连后无法部分重同步（sync_partial_ok不涨），只能全量。建议按「峰值写入速率 ×repl-timeout× 2」计算，单位字节 -
tcp-keepalive未启用或设得过大：内核 TCP 保活比 Redis 自身心跳更早发现 NAT/防火墙静默 kill 连接。必须设为 ≤repl-timeout / 2，推荐300，并确认系统/proc/sys/net/ipv4/tcp_keepalive_time未被压得过低
真正容易被忽略的是：参数调完不持久化、不验证 master_link_status:up 是否稳定、也不看 sync_partial_ok 是否上升——这些才是调优生效的铁证。网络抖动无法消除，但能让复制链路对它“钝感”，靠的从来不是单个参数，而是一组协同生效的约束。
