主节点网卡被打满的典型现象是：INFO replication 中 connected_slaves 持续上涨但 master_last_io_seconds_ago 常大于5，iftop 显示大量发往各从节点的TCP流量，redis-cli --stat 的 in/out 字节数突增且 sync_full 频次升高，表明主节点正高频广播RDB或复制流，网卡已成瓶颈。
主节点网卡被打满的典型现象
执行 INFO replication 时发现 connected_slaves 持续上涨，但 master_last_io_seconds_ago 常大于 5，同时主节点网卡流量监控（如 iftop -P redis）显示大量发往不同从节点 IP:port 的 TCP 流量；redis-cli --stat 中 in/out 字节数突增，且 sync_full 频次升高——这说明主节点正在高频广播 RDB 或复制流，网卡已成瓶颈。
级联复制必须开启的两个配置项
中间层从节点不是“接过来就能转发”，它默认拒绝被下游 REPLICAOF，必须显式放开：
-
replica-serve-stale-data yes：允许中间节点在与主断连期间继续响应下游的复制请求（否则会直接拒绝同步） -
replica-announce-ip和replica-announce-port：必须显式配置为中间节点对外可访问的地址和端口，否则下游节点连接后无法正确识别其身份，导致PSYNC失败或拓扑错乱
注意：replica-read-only yes 可保持默认（无需关闭），级联不依赖中间节点写能力，只用它中继命令流。
如何验证级联是否真正生效
不能只看下游节点的 INFO replication 显示 master_host 是中间节点——还要交叉验证链路完整性：
- 在下游节点（如
redis-6382）执行INFO replication，确认role是slave、master_link_status是up、master_host指向中间节点（如10.0.1.22） - 在中间节点（如
redis-6381）执行INFO replication，确认connected_slaves >= 1，且对应slaveX行中state=online - 在主节点执行
INFO replication，对比connected_slaves数值——应明显低于级联前（例如从 8 降到 2）
若中间节点 INFO replication 中无 slaveX 条目，或主节点 connected_slaves 未下降，说明下游仍直连主节点，级联未生效。
级联后主节点压力下降的关键前提
级联不是配完就减负，效果取决于三个缓冲区参数是否匹配实际负载：
-
repl-backlog-size：主节点只需维持一份环形缓冲区，默认 1MB 完全不够。高写场景建议设为512mb或更高，避免中间节点断连后触发全量同步 -
repl-timeout：主节点对中间节点的超时时间应略宽松（如60），但中间节点对下游的repl-timeout可更激进（如30），防止下游抖动波及主节点 -
client-output-buffer-limit slave：主节点只需为中间节点分配输出缓冲区，因此该配置中hard和soft限值可大幅调低（如从256mb 64mb 60改为64mb 16mb 30），节省内存并降低 fork 压力
层级本身不能超过 2 层——第三层引入的延迟累积和故障扩散风险，往往比网卡压力更难运维。你得先确认压垮主节点的是带宽还是 fork 开销，再决定要不要加中间层。
