确认“同步慢”需先区分现象：slave_repl_offset持续上涨为真慢，长时间不动则为卡死；通过info replication查看master_sync_in_progress、master_sync_left_bytes和lag值判断具体原因。

怎么确认是“同步慢”而不是“卡死”

先别急着调参数，得先分清现象：是 slave_repl_offset 缓慢但持续上涨（真慢），还是长时间不动（已卡）。在从节点执行 INFO replication，重点看三字段：

• master_sync_in_progress 为 1 → 正在全量同步，此时看 master_sync_left_bytes 是否在明显下降
• lag 值稳定在 0 或 1，但 slave_repl_offset 追不上 master_repl_offset → 属于部分同步下的追赶缓慢
• slave_repl_offset 几十秒不变，master_sync_left_bytes 几乎不减 → 不是慢，是传输中断或主节点没发，不是带宽问题，是链路阻塞

为什么调大 repl-backlog-size 反而更慢

盲目把 repl-backlog-size 从默认 1mb 拉到 1gb，可能让从节点更慢——因为部分同步时，主节点要从这个环形缓冲区里逐条读命令、序列化、发出去；缓冲区越大，从节点落后越多，需要重放的命令就越多，而重放本身受制于从节点 CPU 和单线程执行能力。

实操建议：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 先估算真实增量写入速率：redis-cli --stat 观察 in 字段每秒流入字节数，或用两次 INFO replication 的 master_repl_offset 差值除以时间
• repl-backlog-size 设为「峰值写入带宽 × 允许断连时长」即可，比如峰值 3mb/s、容忍断连 30s，设 100mb 足够，不必硬上 1gb
• 同步调高 client-output-buffer-limit slave，但上限建议 ≤ 512mb，避免主节点内存被复制缓冲区吃光

从节点回写命令慢，90% 是它自己扛不住

主节点发得再快，从节点解析执行不过来，slave_repl_offset 就追不上。常见瓶颈不在网络，而在从节点本地：

• 检查 used_memory_peak_human 是否持续升高 → 命令积压在 client output buffer 或 pending query buffer
• 确认 appendonly 是否为 yes：AOF 开启且 appendfsync always 会强制刷盘，直接拖垮重放速度；必须设为 everysec
• 用 top -H -p $(pgrep redis) 看线程 CPU 占用，若主线程（通常是 tid 最小的那个）长期 >80%，说明重放已成瓶颈
• 禁止在从节点上跑业务读请求以外的任何操作，尤其避免 KEYS、SCAN、SUNION 类命令——它们会抢占主线程，让复制彻底停滞

tcpdump 抓包比 INFO 更可信

INFO replication 显示一切正常，但同步就是慢？别信表面数据，直接抓包看真实流量：

• 在主节点执行：tcpdump -i any port 6379 -w sync.pcap，触发同步后几秒内停止
• 用 Wireshark 打开，过滤 tcp.len > 0 and ip.dst == [从节点IP]
• 如果看到大量 64KB~1MB 的连续 TCP 包 → 数据确实在发，问题在从节点接收/执行侧
• 如果只有零星小包（），或根本没包 → 主节点没发，或中间防火墙/NAT/代理截断了大包，不是 Redis 配置问题

真正卡点往往藏在网卡驱动、TCP window scaling 关闭、或云厂商安全组隐式限速里，这些靠 Redis 日志和 INFO 是完全看不到的。