repl-timeout 必须调优，redis 6.0+ 默认60秒易致主从断连并触发“断开→全量→再超时”死循环；应设为网络p99 rtt×3叠加全量同步耗时，生产推荐600秒，同时收紧client-output-buffer-limit slave参数并检查云服务限制、repl-ping-replica-period和tcp-keepalive。
repl-timeout 设置过短是主从同步中断并触发死循环重启的直接诱因，不是“可以考虑”，而是必须调。
repl-timeout 被忽略的默认值陷阱
Redis 6.0+ 默认 repl-timeout 是 60 秒，但这个值在高延迟网络、大 key 同步或主库负载稍高时完全不够用。一旦从节点在该时间内未收到主节点心跳（REPLCONF ACK），主节点会主动断开连接，从节点重连后又因位点丢失被迫发起全量同步——而全量同步本身又可能超时，形成“断开 → 全量 → 再超时 → 再断开”的死循环。
- 现象：日志中反复出现
Connection with slave xxx lost, waiting for it to reconnect和Failed to bind to port 6379（实际是重连风暴压垮了端口队列） - 验证方式：在主节点执行
redis-cli config get repl-timeout，若返回60，且网络 RTT > 15ms，就已处于风险区 - 注意：
repl-timeout控制的是主节点对从节点的心跳等待时间，和客户端timeout、client-output-buffer-limit完全无关，不能混用
怎么设才真正有效
单纯加到 120 或 180 秒仍可能失败——关键要看你的最差同步场景。建议按以下逻辑设：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 基础值 = 网络 P99 RTT × 3（例如实测最大延迟 40ms，则至少 120ms）
- 叠加全量同步缓冲期：若
repl-backlog-size设为 1GB，bgsave + 传输预估耗时约 3~5 分钟，repl-timeout至少设为300（秒） - 生产环境保守推荐：
600（10 分钟），配合config set repl-timeout 600热生效，无需重启 - 避免设为 0（禁用超时）：这会导致异常连接永久滞留，最终耗尽
maxclients
只调 repl-timeout 不够，必须同步收紧 client-output-buffer-limit
repl-timeout 延长后，如果从节点卡住不动，主节点的输出缓冲区（client-output-buffer-limit slave）会持续堆积，直到触发强制断连，前功尽弃。
- 必须同步执行：
config set client-output-buffer-limit "slave 1024mb 512mb 60"（即：硬限 1GB，软限 512MB 持续 60 秒） - 软限值（512MB）要 ≥ 主节点每秒写入量 ×
repl-timeout，否则缓冲区会在超时前就溢出 - 检查是否生效：
redis-cli config get client-output-buffer-limit，确认返回值含slave对应项
为什么改完还是重启？检查这三个隐藏点
即使 repl-timeout 和缓冲区都调了，死循环仍可能发生：
- 云厂商 Redis 服务（如阿里云、腾讯云）可能屏蔽
config set，需在控制台配置页修改，命令行不生效 - 从节点自身设置了
repl-ping-replica-period（默认 10 秒），若它发心跳太慢，主节点等不到 ACK；建议同步设为30 - 主节点
tcp-keepalive过短（默认 0），内核可能提前回收空闲连接；设为300可保活
这些参数不联动调整，repl-timeout 就只是纸面延长。
