repl-timeout过短会导致主节点主动断连，形成“断开→全量→再超时”死循环；必须根据网络P99 RTT×3叠加全量同步耗时调优，生产推荐600秒，并同步收紧client-output-buffer-limit slave参数。
repl-timeout 设置过短导致连接被主动断开
Redis 主从同步时，repl-timeout 控制主节点等待从节点响应的最长时间。默认值是 60 秒，一旦超时，主节点会主动关闭连接并记录 Connection reset by peer。这不是网络中断，而是主节点“自己动手”发 RST 包。
- 现象：从节点日志频繁出现
Master timeout, disconnecting...，紧接着主节点报error 104 - 验证方式：执行
config get repl-timeout查当前值；再用info replication看master_last_io_seconds_ago是否常接近或超过该阈值 - 典型诱因：跨机房同步（高延迟）、从节点 CPU 或磁盘 IO 过载（响应慢）、主节点写入压力大导致命令积压延迟发送
- 建议值：内网环境可保持默认；跨 AZ 或公网部署建议调至 300–600；若从节点负载不稳，需同步优化其资源而非一味拉长 timeout
复制缓冲区（repl-backlog）溢出触发重连与全量同步
主节点靠 repl-backlog 缓存最近写命令，供从节点断连后做部分重同步（PSYNC）。一旦该缓冲区被写满，新命令覆盖旧命令，从节点再连就无法找到断点，只能发起全量同步——而全量同步期间主节点仍持续写入，加剧缓冲区压力，形成恶性循环。
- 现象：从节点反复断连、重连，
INFO replication中slave_repl_offset与master_repl_offset差值剧烈跳变，且repl_backlog_active常为 1 但repl_backlog_histlen恒等于repl_backlog_size - 关键参数：
repl-backlog-size默认 1MB，对高写入场景严重不足；repl-backlog-ttl决定空闲时缓冲区是否释放（0 表示永驻） - 计算参考：若主节点每秒写入 5MB 数据，
repl-backlog-size至少设为5 * repl-timeoutMB，留出安全余量 - 注意：增大
repl-backlog-size会占用主节点额外内存，需权衡
从节点加载 RDB 时主节点连接被中间设备切断
全量同步阶段，主节点生成 RDB 并传输，此时连接处于长时数据流状态。很多云厂商 LB、NAT 网关或防火墙对“无应用层心跳”的 TCP 连接有默认超时（常见 300–900 秒），一旦超过即发 RST 断开连接，表现为 Connection reset by peer，但错误实际发生在网络路径中段，而非 Redis 进程本身。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 现象：RDB 传输到 70%–90% 时突然中断，从节点日志显示
IOERR error or timeout reading from socket，主节点无对应错误日志 - 验证方式：抓包看是否有来自非主/从 IP 的 RST 包；检查 LB 控制台会话超时设置；对比
net.ipv4.tcp_keepalive_time（默认 7200s）是否远大于中间设备限制 - 解法优先级：在主节点启用
tcp-keepalive（redis.conf 中设tcp-keepalive 60），让内核每 60 秒发 keepalive 探针；其次调整 LB 超时时间 ≥ RDB 预估最大传输时长 + 60 秒 - 避坑：不要依赖客户端 keepalive，Redis 同步走的是服务端直连，keepalive 必须由 Redis 进程所在系统内核发出才有效
从节点执行 SLAVEOF/REPLICAOF 后清库失败或卡住
从节点执行 REPLICAOF 切换主库时，若原数据量大或磁盘 IO 差，FLUSHALL 清库操作可能耗时数秒甚至更久。此期间从节点无法响应主节点的同步请求，导致主节点判定超时并重置连接——尤其当 repl-timeout 过短或主节点正忙于写入时。
- 现象：从节点刚执行
REPLICAOF就断连，日志出现MASTER <-> REPLICA sync: Flushing old data后无后续，主节点报 timeout - 关键线索：
INFO replication中slave_repl_offset长期为 0，master_link_status反复在up/down间跳变 - 缓解手段：避免在业务高峰期执行主从切换；确保从节点磁盘使用率 DEBUG RELOAD（慎用）或手动
FLUSHALL再启动同步 - 本质矛盾：清库是强一致性前提，但耗时不可控。没有绕过它的办法，只有前置控制和资源保障
真实环境里，这四类原因常交织出现——比如 repl-backlog 溢出引发重连，重连又触发清库，清库慢再撞上 repl-timeout，最后被 LB 截断。排查必须按链路顺序：先确认是哪一端发的 RST（主？从？中间？），再锁定触发动作（超时？缓冲区满？清库卡住？），参数调优永远要配合可观测性数据，而不是拍脑袋改数字。
