主从复制真实延迟看master_repl_offset与slave_repl_offset差值（字节），持续上涨即真延迟；常见根因是网络带宽瓶颈、repl-backlog-size过小（建议≥128MB）、从节点I/O或CPU过载。
主从复制延迟怎么看？INFO replication 里 master_repl_offset 和 slave_repl_offset 差值持续上涨就是真延迟
别只盯着 lag=0 这个字段——它只反映心跳延迟，不是真实复制积压。真正要看的是两个 offset 的差值，单位是字节。差值每秒涨几百 KB 甚至 MB，说明从节点追不上主节点写入节奏。常见现象包括：从库读到旧数据、哨兵误判从库下线、WAIT 命令超时失败。
网络和带宽瓶颈是最常被忽略的根因
- 主从之间跨机房、跨云厂商、走公网或共享交换机，
tcp_rmem/tcp_wmem 内核参数没调优，小包多导致吞吐上不去
- 主节点出口带宽打满（比如单实例写入 80MB/s，而网卡只有 1Gbps ≈ 125MB/s，但实际可用约 90MB/s，余量不足）
- 从节点所在宿主机磁盘 I/O 高（AOF rewrite + RDB save 同时触发），导致
repl-backlog 缓冲区写入阻塞
tcp_rmem/tcp_wmem 内核参数没调优，小包多导致吞吐上不去repl-backlog 缓冲区写入阻塞验证方法：在从节点用 netstat -s | grep -i "retransmit" 查重传；用 iftop -P 6379 看实时流量；用 iostat -x 1 观察 %util 和 await。
repl-backlog-size 设太小会直接放大延迟抖动
这个缓冲区是环形的，主节点靠它暂存最近写命令供断连后从节点追赶。默认 1MB 完全不够用——如果主节点 QPS 高、命令平均体积大（比如 LPUSH 大 list）、或从节点偶发卡顿几秒，backlog 就会被覆盖，触发全量同步（SYNC），进一步拖垮从节点 CPU 和带宽。
- 估算公式：
repl-backlog-size = (主节点平均写入带宽 MB/s) × (预期最大断连恢复时间 s) × 2 - 生产建议起步 128MB，写入峰值稳定在 20MB/s 的集群可设为 256MB
- 必须配合
repl-backlog-ttl 0（禁用自动释放），否则空闲时 backlog 被清掉，下次断连仍可能丢数据
从节点自身负载过高会形成负向循环
延迟变大 → 从节点积压更多待执行命令 → 更多内存分配/过期键清理/渐进式 rehash → CPU 升高 → 复制线程调度更慢 → 延迟继续变大。这不是理论，是 Redis 6.0+ 在高负载下真实发生的调度竞争。
- 检查
INFO cpu中used_cpu_sys_children是否异常高（说明 fork 开销大） - 确认没开
lazyfree-lazy-eviction yes且同时大量 key 过期（这会让主线程忙于删除） - 避免在从节点开启
notify-keyspace-events，它会在每个操作后触发额外事件处理 - 监控
evicted_keys和expired_keys每秒速率，若 > 1k/s，考虑拆分或改用 LFU 策略降低驱逐压力
真正难处理的往往是复合问题：比如 backlog 不够 + 从节点磁盘慢 + 主节点启用了 replica-serve-stale-data no，此时哪怕延迟只到 500ms，客户端就读不到数据。盯住 offset 差值，再一层层往下切资源指标，比调参更重要。
