Redis主从复制风暴是因所有从节点直连单主节点导致CPU、网络、磁盘IO过载；通过树状拓扑分层卸载（主节点→中间节点→末端从节点），可分散压力并需调优中间节点配置与监控。
Redis主从复制风暴是怎么发生的
主节点同时给大量从节点同步RDB或传播写命令时，CPU、网络带宽、磁盘IO会突然拉满，导致主节点响应变慢甚至超时断连。典型现象是 INFO replication 里 connected_slaves 数量剧烈波动，master_repl_offset 追不上，从节点反复重连。
根本原因不是“从节点太多”，而是所有从节点都直连同一个主节点——相当于把全部复制压力堆在单点上。
用树状拓扑把复制压力分层卸载
让部分从节点升级为“中间主节点”，只从上层同步，再向下级提供服务。这样IO和网络压力就分散到多台机器，主节点不再承担全量复制负载。
- 第一层：原主节点（
master-A）只服务少量关键从节点（比如2–3个），不直接挂10+个从库 - 第二层：选2台稳定实例作为
intermediate-master-B和intermediate-master-C，配置replicaof master-A 6379 - 第三层：其余从节点分别连
intermediate-master-B或intermediate-master-C，形成扇出结构
注意：中间节点必须开启 replica-serve-stale-data yes 和 replica-read-only yes，否则可能被误写；若需写入，请改用 Redis Cluster 或分片代理方案。
中间节点的持久化与故障切换风险
中间节点既是副本又是主节点，它的 RDB/AOF 落盘行为会直接影响下级同步延迟和恢复时间。如果它崩溃，整棵子树都会断连。
- 务必关闭中间节点的
save配置（设为空列表），避免 fork 阻塞主线程；用redis-cli --rdb定期手动触发快照更可控 - 不要依赖中间节点做自动故障转移——
redis-sentinel默认只监控顶层主节点，不会为中间层选举新主 - 如果中间节点挂了，下级从节点会报错
NOAUTH Authentication required或Connection refused，实际是连接丢失，不是认证问题
验证拓扑是否生效的关键指标
光看 INFO replication 不够，得交叉比对三层节点的偏移量和连接状态。
- 在
master-A上执行role，确认connected_slaves是 2（不是10+） - 在
intermediate-master-B上执行role，确认角色是slave，且master_link_status为up - 在任意末端从节点上执行
info replication | grep master_repl_offset，数值应略小于其直连中间节点的master_repl_offset，差值最好控制在 10MB 以内
真正难控的是中间节点的内存增长速度——它既缓存数据又转发命令，容易因 client-output-buffer-limit 被踢，记得调大 client-output-buffer-limit replica 的 hard/soft 值。
