集群扩容时的数据再平衡会短时占用网络带宽，这是分布式存储和数据库集群的固有代价，但通过合理的限速、滚动迁移和业务低峰期操作，完全可以把影响控制在可接受范围内。
先说结论：再平衡为什么“吃”带宽
每个节点都在忙着把自己手上的数据分片复制给新加入的兄弟节点,同时还得接收别人甩过来的新分片，这个过程不像拷贝文件那么简单，它涉及大量的元数据同步、数据校验、增量追平，集群的副本数越多、单分片体积越大，网络里的数据包就越是挤成一团，你可以想象一条高速公路本来双向八车道跑得好好的，突然一批满载的大卡车（数据块）并线进来，其他小车（正常业务请求）自然会被堵一会儿。
这里有一个容易忽略的点：再平衡不是“悄悄”进行的，它默认使用尽可能多的带宽去加速完成迁移，因为在设计者的逻辑里，迁移结束得越早，集群恢复健康状态就越快，所以如果你不主动干预，它就会贪婪地占用网络资源。
集群扩容带宽不足怎么办
“扩容的时候业务突然卡顿，监控面板上网络流量飙红”这是运维群里最常见的求助画面，带宽不足不是真的物理带宽不够，而是再平衡机制默认“全力冲刺”导致的，解决办法其实不复杂，核心思路就是给迁移过程加一个水龙头。
先判断你的瓶颈在哪
动手之前,先确认网络延迟高是再平衡引起的，还是其他原因，登录任意一个数据节点，执行：
sar -n DEV 1 5
观察rxkB/s和txkB/s，如果某块网卡的流量远超日常基线的两倍以上，同时CPU和磁盘IO都还算正常，那基本可以锁定是数据搬迁在抢带宽，另一个快速验证方法是查看集群自身的迁移任务列表，比如对于Elasticsearch：
GET _cat/recovery?v&active_only=true
如果返回了大量relocating状态的shard，那就坐实了。
限速的几种实操姿势
第一招：修改集群的动态参数，大部分分布式系统都支持在线调整迁移速度，例如Elasticsearch可以设置：
PUT _cluster/settings
{
"persistent" : {
"cluster.routing.allocation.node_concurrent_recoveries" : 2
}
}
把并发恢复数从默认的4-6降到2，效果立竿见影，Cassandra则通过stream_throughput_outbound_megabits_per_sec参数限制流式传输带宽，设成200或者300，别让它放开跑。
第二招：用cgroup或者TC做硬限制，如果集群软件本身没有限速参数，比如某些自研系统或老版本组件，那就直接对进程的网络流量做控制，用tc命令给数据节点打上令牌桶：
tc qdisc add dev eth0 root tbf rate 500mbit burst 32kbit latency 400ms
把带宽压到500Mbps,业务流量就能从抢车位变成正常通行，这里注意不要限制得太狠，否则迁移时间会拉长到不可接受，建议从日常峰值带宽的50%开始调。
第三招：分批次迁移，把整个集群分成几个机架或可用区，一次只允许一个区域内的节点参与再平衡，这种操作需要你对集群的rack感知有所了解，但效果比单纯限速更精细，因为你能控制“谁在什么时候搬家”。
扩容数据迁移影响业务吗
很多团队不敢做扩容,就是怕迁移过程把线上服务搞垮，答案是可以做到基本无感，但前提是你得尊重一个规律：再平衡的冲击是短时且可控的，扛过最初几分钟就好了，为什么这么说？因为迁移遵循“先传数据、后切换路由”的原则，新节点在数据追平之前，不会被分配读写流量，真正的风险窗口出现在两个时刻：一是迁移刚开始时的带宽抢占，二是最后一小部分增量数据追赶时的锁竞争。
把迁移时间窗放在业务低谷
行业共识认为,在线扩容的最佳时机是凌晨两点到六点，这不是玄学，而是因为此时带宽利用率和请求延迟都处于最低位，如果你用的是云服务器，还可以临时升级带宽套餐，迁移完再降回来，成本只多几十块，据主流云厂商公开的计费信息，按日调整带宽是可行的。
观察哪些指标来判断影响
不要只看网络流量,你要看业务侧的真实感受，重点盯三个数：
- P99延迟：如果平时是10ms，迁移时跳到50ms以上，且持续超过5分钟，说明限速需要再调低
- TCP重传率：超过3%说明网络已经拥塞到丢包了，这时候迁移任务本身也会变慢，得不偿失
- 活跃连接数：这个数字突然掉头向下，说明客户端在超时重连，赶紧检查负载均衡层是否触发了熔断
一个反直觉的优化：先调大副本因子再缩扩容
实际场景中,如果你要新加三个节点，别直接把这六个节点的数据全量打散，行业经验比较丰富的老运维会先给索引或分片临时增加副本数，让新节点先接收一部分副本流量，然后再发起再平衡，这么做的优势是迁移的数据量更少因为副本本身就是多份的，新节点只是接收其中一份已有副本，而不是重新计算和复制主分片，听起来有点绕，但操作路径其实是：调大number_of_replicas -> 等待副本初始化完成 -> 触发reroute -> 扩容，整个过程对带宽的占用能降低将近一半。
再平衡期间的业务降级策略
如果你的业务对延迟极度敏感,比如实时交易系统，光靠限速还不够，需要主动给系统“让路”。
读写分离与队列削峰
在扩容期间,把非核心的读流量切到只读副本上，写流量继续走主分片，同时给消息队列增加消费延迟，比如Kafka的消费者拉取频率从100ms调到500ms，人为削峰，这有点“饮鸩止渴”的嫌疑，但只用在迁移那几小时，完全可接受。
客户端重试与超时设置
很多服务卡顿是客户端等不及造成的,检查一下你的客户端超时配置，如果连接超时设置的是2秒，建议临时调整到5秒，读取超时从3秒调到10秒，这样即使网络波动造成单次请求变慢，也不会直接触发熔断和雪崩，等迁移完成后，再把这些参数调回来。
用监控告警守住底线
设定一个硬性告警：如果网络延迟持续超过200ms，或者错误率超过1%，就自动暂停再平衡任务，很多系统支持暂停迁移，比如Elasticsearch的
cluster.routing.allocation.enable设为none，HDFS的dfs.datanode.balance.bandwidthPerSec改成0，宁可让集群处在“未平衡”状态，也别让它把业务拖死，有些团队担心暂停迁移会导致数据不一致，实际上不会再平衡是可中断的，下次触发时会从断点继续。
常见场景问答
服务器扩容网络延迟高，是因为机房带宽被限速了吗？
不一定是,物理带宽超卖在低端机房确实常见，但更大可能是你的扩容任务和日常备份任务撞到一起了，检查一下是否在同一个时间段有定时全量备份或者日志采集任务在跑，如果是，把备份窗口错开即可，如果查完发现没有冲突，再去看数据节点的网卡是否开启了流控，某些网卡的自动协商会把速率降到一半。
对比在线扩容和离线扩容，哪个更适合生产环境？
在线扩容不用停机,但会占用网络带宽；离线扩容需要停止服务，但迁移速度极快，对于7x24小时的业务，只能选在线扩容，然后用限速和低峰期操作来消解影响，对于可以接受短暂停机的内部系统，离线扩容反而更省心，因为你不需要考虑带宽争抢，直接把节点从集群中摘除，用物理拷贝方式把数据盘挂载到新节点上，几十分钟就能完成一个几TB的节点迁移。
扩容完成后为什么网络还是慢？
再平衡任务显示完成不代表网络立刻恢复,新节点上线后，集群会有一段时间的热点调整，比如原本压在某两个节点上的读请求开始向新节点扩散，新的网络连接建立也会带来突发流量，建议观察半小时，如果流量仍居高位，检查是否有未清理的孤儿分片或者正在执行的手动flush操作。
扩容这件事,说到底就是“给数据搬家”，搬家的动静大小，取决于你提前准备了什么样的临时交通管制，记住核心结论：数据再平衡的带宽占用是短时的，它怕的是不可控，不怕短暂拥挤，把限制参数调好、时间窗口选好、告警盯住，扩容完全可以成为一次无感的例行维护。