级联复制可降低主节点cpu 30–40%、网络流量60%+，但层级不宜超2层；一主多从在高写入时会因bgsave线性增加、复制缓冲区压力及断连重连触发全量同步而拖垮主节点。

支持，但主库的全量同步压力会线性增长，不是“自动优化”的并发。

多个从库触发全量同步时，主库会为每个从库单独执行 bgsave

当多个从库首次连接或断连重连（且无法复用 psync 偏移量）时，主库对每个从库都会走一遍全量复制流程：

• 每个从库都会触发一次独立的 bgsave，生成各自的 RDB 文件（除非启用 repl-diskless-sync yes）
• 主库内存中会同时维护多个 replication buffer，分别缓存各从库在 RDB 生成期间的写命令
• CPU、内存、磁盘 I/O 和网络带宽消耗随从库数量上升而显著增加

repl-diskless-sync yes 能缓解磁盘压力，但不解决并发瓶颈

该配置让主库跳过本地写 RDB 文件，直接通过 socket 把 RDB 流式发给从库。但它只解决「磁盘写入」这一个环节：

Redis Skill - 高性能缓存管理

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

下载

• 仍需为每个从库单独做内存快照（bgsave 的 fork + copy-on-write 开销仍在）
• 网络传输仍是串行发送：主库不会把一份 RDB 同时广播给多个从库，而是逐个发送
• 若从库网络慢，会拖慢后续从库的同步启动时间

级联复制（replicaof 指向从库）是实际生产中更可控的方案

避免所有从库直连主库争抢资源，典型结构：Master → Slave1 → Slave2：

• Slave1 承担了主库的 RDB 生成和首份传输压力
• Slave2 向 Slave1 发起同步，主库完全不感知
• 需注意 Slave1 的网络出口带宽和 CPU 负载，它成了新的单点瓶颈
• 级联层级不宜超过 2 层，否则复制延迟会明显放大

真正需要横向扩展读能力时，别只堆从库数量——得结合哨兵或集群模式，并监控 info replication 中的 master_repl_offset 和各 slave_repl_offset 差值，这个差值持续变大，说明复制已开始滞后，再加从库只会让问题更隐蔽。