应对Redis同步超时引发的死循环重启_适当延长repl-timeout超时时间

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 秒仍可能失败——关键要看你的最差同步场景。建议按以下逻辑设：

• 基础值 = 网络 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 就只是纸面延长。