根本原因是默认参数组合无法保障抖动期间PSYNC所需的偏移量连续性：repl-timeout（60秒）、repl-backlog-size（1MB）和tcp-keepalive（0）协同失效，导致20–40秒抖动即超出backlog覆盖范围，触发强制全量同步。
根本原因不是网络抖动本身，而是默认参数组合在抖动窗口内无法支撑部分重同步（PSYNC）所需的偏移量连续性。 默认的 repl-timeout（60秒）、repl-backlog-size（1MB）和 tcp-keepalive（300秒）三者叠加，在中等写入压力下，一次持续 20–40 秒的抖动就足以让从节点 offset 落后超出 backlog 覆盖范围，导致主节点返回 Partial resynchronization not possible (no cached master)，强制进入全量同步流程。
repl-backlog-size 太小：缓冲区被快速覆盖
复制积压缓冲区是环形的，只保留最近写入的命令流字节。它不按时间算，而按字节数算——只要新命令写入导致旧 offset 被覆盖，断连重连时就再也找不回那个位置。
- 默认
repl-backlog-size是 1048576 字节（1MB），对每秒写入 50KB 的实例，仅能覆盖约 20 秒的写入量 - 一次跨机房路由收敛或交换机瞬断，实际闪断常达 30–50 秒；抖动期间主库还在持续写入，backlog 很快被填满并覆盖旧数据
- 验证方法：
redis-cli info replication | grep -E "master_repl_offset|slave_repl_offset|repl_backlog_active|repl_backlog_size"，计算差值是否 >repl_backlog_size - 调优建议：按「峰值写入速率 × 预期最大断连窗口」估算，例如 100KB/s × 120 秒 = 12MB → 设为
12582912；生产环境建议不低于 64MB
repl-timeout 设置过长或过短都危险
这个参数控制主节点判定从节点“失联”的阈值，但它同时反向决定心跳频率（默认每 repl-timeout / 2 秒发一次 REPLCONF ACK）。设得不合理，会放大抖动影响。
- 设为 60 秒：心跳间隔 30 秒，一次 35 秒抖动就会触发超时断连；但设太小（如 10 秒）又容易误杀正常高延迟从节点
- 真实瓶颈常不在网络层，而在从节点自身：CPU 过载、BGSAVE fork 卡顿、慢 Lua 脚本阻塞事件循环，都会导致 ACK 延迟发送，被主节点误判为断连
- 推荐值：跨机房场景建议 120–180 秒（心跳间隔 60–90 秒），配合监控确认平均 RTT + P99 抖动上限后再加冗余
- 注意：
config set repl-timeout 120仅运行时生效，必须写入redis.conf并重启或CONFIG REWRITE持久化
TCP 层保活缺失：连接在中间设备上静默超时
Redis 应用层心跳之外，底层 TCP 连接可能被防火墙、NAT 网关或云厂商负载均衡器主动回收——尤其当应用层无数据交互超过其 idle timeout（常见 60–300 秒）时。
- 默认
tcp-keepalive是 0（禁用），意味着完全依赖 Redis 自己的心跳；一旦 Redis 心跳因上述原因延迟，TCP 连接已在中间链路被掐断，主节点收不到 FIN，只能靠repl-timeout被动发现 - 开启后（如设为 60），内核每 60 秒发一个 TCP keepalive probe，能更快暴露链路中断，避免“假连接”状态拖长故障窗口
- 需配套调低内核参数：
net.ipv4.tcp_keepalive_time（建议 60）、net.ipv4.tcp_keepalive_intvl（建议 10）、net.ipv4.tcp_keepalive_probes（建议 3） - 验证方式：
ss -i src :6379查看连接的rcv_rtt和rto，异常升高往往预示 TCP 层已开始重传
真正难处理的不是单个参数，而是它们之间的耦合关系：增大 repl-backlog-size 能扛更久抖动，但若 tcp-keepalive 关闭，连接可能早就在第 90 秒被 SLB 清掉，backlog 再大也救不回那次断连；调高 repl-timeout 能减少误断，但若心跳间隔拉得太长，又会让部分重同步的窗口变得更窄。这些细节在配置变更后必须用 redis-cli --latency-history -i 1 模拟抖动+观察 INFO replication offset 差值变化来实测验证，不能只靠理论估算。
