repl-timeout应设为p95 rtt+2–3秒，client-output-buffer-limit slave第三参数需≥repl-timeout，tcp-keepalive须匹配云平台空闲超时，且须用tcp抓包而非ping验证链路真实质量。
repl-timeout设太小会直接触发假断连
主从之间一次 100ms 的延迟叠加丢包，就可能让 master_last_io_seconds_ago 超过默认 60 秒，导致主节点主动断开连接。这不是故障，是配置和现实不匹配。
必须基于真实 P95 RTT 设定：repl-timeout = P95 值 + 2–3 秒。例如采集一小时 INFO replication 中的 master_last_io_seconds_ago，P95 是 12.3 秒，那就设为 15。
- 绝对别用文档里“建议 60”或“保守设 120”——前者抖动即断，后者真宕机要等两分钟才 failover
- 云环境优先查 VPC 流量监控（如阿里云 flowlog、AWS CloudWatch），取 P99.5 更稳
- 调完立刻验证：
redis-cli config get repl-timeout
client-output-buffer-limit slave 必须同步放大
repl-timeout 加长后，主节点不会停下发数据，但从节点卡在响应阶段，输出缓冲区就会持续堆积。默认 client-output-buffer-limit slave 256mb 64mb 60 在抖动期间极易被触发强制断连。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 第三个参数（时间阈值）必须 ≥
repl-timeout值，比如repl-timeout 90，则至少设为90 - 内存宽松场景可设为
512mb 128mb 120，但注意：该缓冲区不计入maxmemory，监控容易漏掉 - 验证是否生效：
redis-cli config get client-output-buffer-limit，确认返回值已更新
tcp-keepalive 不配等于白调前两个参数
即使 repl-timeout 和缓冲区都设对了，云环境里的 NAT 网关、SLB、安全组仍可能静默 kill 掉“空闲连接”。这不是 Redis 的问题，是底层网络设施保活策略冲突。
- 启用
tcp-keepalive 300（每 5 分钟发一次 TCP 保活包） - 更要匹配云平台空闲超时：AWS ALB 默认 4000 秒，阿里云 SLB 多为 60–300 秒，把
tcp-keepalive设为略小于该值（如 240） - 检查是否生效：
redis-cli config get tcp-keepalive；再用ss -i | grep :6379看ts sack字段是否稳定变化
别只信 ping，要用 TCP 层真实抓包看重传
ICMP 的 ping 和 Redis 复制走的 TCP 完全是两套路径，QoS、中间设备策略都不同。真正影响同步的是重传、SACK、窗口满这些 TCP 行为。
- 主从节点同时跑：
tcpdump -i any port 6379 -w redis-repl.pcap，Wireshark 里重点看 “Retransmission” 和 “TCP Window Full” - 主节点执行：
mtr --tcp -P 6379 <slave-ip></slave-ip>，定位哪一跳丢包率 > 0.5% 或延迟跳变 - 检查网卡队列：
iftop -P 6379或ss -i | grep :6379，若rcv_space长期接近 0，说明接收窗口被压满
