一主多从在高写入时拖垮主节点，因每增一个从节点，主节点网络带宽、cpu及复制缓冲区压力均线性增长，断连重连易触发全量同步致bgsave飙升；级联复制通过让部分从节点连接中间从节点（需开启log_slave_updates并配置replicaof），可降低主节点cpu 30–40%、网络流量60%+，但层级不宜超2层以防延迟累积和故障放大。
为什么一主多从在高写入时会拖垮主节点
主节点每执行一条写命令，就要把命令发给所有从节点。当从节点数量增加，主节点的网络带宽和 CPU 就会线性增长——不是“稍微慢一点”，而是 replicaof 连接数翻倍，PSYNC 命令广播量也翻倍。更关键的是，主节点的复制缓冲区（repl-backlog）要为每个从节点维护独立的偏移量追踪，但实际只有一份环形缓冲区；一旦某个从节点断连重连又错过缓冲区范围，就会触发全量同步，导致主节点反复执行 BGSAVE，磁盘 I/O 和 fork 开销直接飙升。
级联复制怎么配：用中间从节点当“代理主”
核心是让部分从节点不直连主节点，而是连到另一个从节点上，形成树状结构。这需要两步操作：
- 先确保中间节点（比如
redis-6381）已成功完成对主节点（redis-6380）的全量/增量同步，且info replication中显示role:slave且master_link_status:up - 再让下游节点（比如
redis-6382）执行REPLICAOF 127.0.0.1 6381，而不是指向6380 - 注意：中间节点必须显式开启
replica-read-only no（默认是yes），否则它拒绝接收来自下游的REPLICAOF请求；但一般不建议关，更稳妥的做法是保持只读，仅用它转发复制流
验证是否生效：在 redis-6382 上执行 info replication，看 master_host 是 127.0.0.1、master_port 是 6381，且 role 是 slave；同时在 redis-6381 的输出里确认 connected_slaves ≥ 1。
级联后主节点压力下降多少？关键看三个参数
级联不是“加个节点就自动减负”，效果取决于配置匹配度：
-
repl-backlog-size：主节点只需维持一份缓冲区，默认 1MB。级联后，只要中间节点没断连，下游断连重连由中间节点用自己的缓冲区服务，主节点完全不感知 -
repl-timeout：主节点等待中间节点 ACK 的超时时间不变，但下游节点的超时由中间节点控制，主节点连接数减少，心跳压力明显下降 -
client-output-buffer-limit slave：主节点只为中间节点分配输出缓冲区，不再为每个下游节点单独分配，内存占用可降低 50% 以上（实测 5 个直连从节点 vs 1 中间 + 4 下游）
典型场景下，主节点的 CPU 使用率下降 30–40%，网络发送字节数下降 60%+，尤其在突发写入（如批量导入）时差异更明显。
容易被忽略的坑：级联链不能太长，且必须监控中间节点健康
级联层级建议最多 2 层（主 → 中间从 → 下游从）。超过 2 层会带来两个硬伤：
- 延迟逐层累积：主 → 中间从 已有毫秒级延迟，中间从 → 下游从 再叠加一次，最终下游从节点的
master_repl_offset可能比主节点落后数百毫秒甚至秒级，在强一致性要求场景下不可接受 - 单点故障放大：中间节点挂了，它下面所有下游节点都会触发重连+全量同步，瞬间打爆主节点，形成雪崩
- 监控盲区：
redis-cli -p 6380 info replication看不到下游节点状态，必须逐层登录检查connected_slaves和master_link_status
真正落地时，中间节点本身就得按主节点标准做监控（CPU、内存、repl_ack_age）、限流（maxmemory-policy 避免 OOM）、并预留 failover 能力（比如用哨兵管理中间节点）。否则省下的资源，迟早被一次故障吃掉。
