repl-timeout 应设为 P99 RTT 的 2～3 倍，如 P99 RTT 为 120ms 则建议 30 秒；需协同调整 repl-backlog-size、repl-backlog-ttl 和 tcp-keepalive，并验证 sync_partial_ok 上升及 master_link_status 稳定。
repl-timeout 设置多少才够用
默认 repl-timeout 是 60 秒，但这个值在高延迟或偶发丢包的网络中极易触发主从断连。不是越大越好，而是要覆盖「单次网络抖动持续时间 + 主从间最大 RTT」。建议先用 ping -c 10 和 redis-cli -h 测出 P99 RTT，再乘以 2～3 倍——例如实测 P99 RTT 是 120ms，那么设为 repl-timeout 5（秒）就太激进，repl-timeout 30 更稳妥。
只调大 repl-timeout 不解决根本问题
单纯加 repl-timeout 只是延长断连判定时间，无法避免以下真实风险：
- 主节点在超时后会主动关闭与从节点的连接，触发
REPLICAOF NO ONE行为（从节点降级为独立主） - 从节点重连后若复制偏移量已不在主节点的
repl-backlog中，会强制全量同步（bgsave + RDB 传输），带来 CPU 和带宽尖峰 - 若主节点启用了
min-replicas-to-write，超时期间可能直接拒绝写入
配套必须调整的三个参数
repl-timeout 必须和另外三个参数协同调整，否则缓冲效果打折扣：
-
repl-backlog-size：至少设为峰值写入量 ×repl-timeout。例如每秒写入 2MB，repl-timeout 60，则repl-backlog-size 128mb起步（注意单位是字节，配置里写134217728或128mb） -
repl-backlog-ttl：默认 0（永不过期），建议保持 0，避免闪断恢复后因 backlog 被清空而被迫全量同步 -
tcp-keepalive：设为 300（秒），让内核主动探测连接存活，比依赖 Redis 自身心跳更早发现中间设备（如 NAT、防火墙）静默丢连接
如何验证调整是否生效
别只看 INFO replication 输出，重点观察三处日志和指标：
- 主节点日志中是否还有
Connection with replica .* lost或Timeout waiting for bulk write - 从节点执行
INFO replication，检查master_link_status:up是否稳定，以及master_last_io_seconds_ago是否长期 ≤repl-timeout - 用
redis-cli -h观察--stat sync_partial_ok计数是否明显上升——说明部分重同步成功，没退化成全量
网络闪断本身不可消除，能做的只是让复制链路对它的反应更“钝感”。真正容易被忽略的是：repl-timeout 生效的前提是主从之间 TCP 连接未被中间设备提前 kill，所以 tcp-keepalive 和防火墙 idle timeout 的配合，比单纯调大这个数值重要得多。
