必须调大repl-timeout，否则“断开→全量→再超时”死循环无法避免；因redis 6.0+默认60秒太短，网络延迟或全量同步耗时超限即触发断连重试，形成稳定重启风暴，生产推荐设为600秒并同步收紧client-output-buffer-limit。
必须调大 repl-timeout，否则“断开→全量→再超时”死循环无法避免。
为什么默认60秒会引发死循环
Redis 6.0+ 默认 repl-timeout 是 60 秒，但这个值在真实生产环境里几乎总是不够用。主节点每秒发一次 REPLCONF ACK 心跳，从节点只要连续 60 秒没收到，就主动断连；重连后发现复制偏移量（master_repl_offset）已超出 repl-backlog 范围，只能触发全量同步；而全量同步本身又可能耗时数分钟——于是再次超时、再次断连，形成稳定复现的重启风暴。
典型现象包括：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完全无关，不能混用 - 设为 0（禁用超时）不可取：异常连接会永久滞留，最终耗尽
maxclients
怎么设才真正有效
单纯加到 120 或 180 秒仍可能失败。关键要看你最差的同步场景：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 叠加全量同步缓冲期：若
repl-backlog-size设为 1GB，bgsave+ RDB 传输预估耗时约 3~5 分钟，repl-timeout至少设为300 - 生产环境保守推荐：直接设为
600（10 分钟），执行config set repl-timeout 600热生效，无需重启 - 注意：
repl-ping-replica-period（默认 10 秒）必须明显小于repl-timeout，建议保持至少 3 倍差距，否则网络抖动丢一个 PING 就可能误判
只改 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-backlog-size和client-output-buffer-limit必须同时调大：前者决定“能追多远”，后者决定“能发多快”，高压下两者都容易溢出
改完还是反复中断？先查这三个隐藏点
即使参数都调了，死循环仍可能发生：
- 主从 Redis 小版本不一致（如主是 7.2.5，从是 7.0.12）：握手阶段静默失败，日志只显示
MASTER SLAVE sync: receiving bytes from master，无报错也不重试 - SELinux 或云服务商安全组拦截了复制端口（除 6379 外，主从间还可能用其他端口传 RDB）
- 慢查询阻塞主线程：比如
keys *或对大 hash 执行hgetall，导致主节点无法及时响应REPLCONF ACK
最易被忽略的是版本校验——它不报错、不告警，只让同步永远卡在握手第一步。
