集群扩容时的数据再平衡会短时占用网络带宽，但这属于可控的瞬态行为，通过合理的限速和分批次迁移，完全可以把对业务的影响降到最低。
数据再平衡为什么非要动网络带宽
集群扩容不是简单把新节点加进去就完事,以常见的分布式存储或缓存集群为例，每个节点只负责一部分数据分片，新节点加入后，系统必须把原有节点上的部分分片搬运过来，让所有节点的数据量重新拉平，这个搬运过程，数据要在网络间流动，带宽占用自然就出现了。
数据搬运的本质是分片迁移
分片迁移时,源节点要把数据读出来，序列化后通过网络发给目标节点，目标节点接收、写入、确认，源节点再删除旧数据，每一步都依赖网络，如果集群有几十个节点同时搬迁分片，瞬时网络流量会翻好几倍。
行业共识认为，迁移期间的带宽占用峰值，通常能达到正常业务流量的30%到50%，在千兆内网环境下，这就意味着数十MB/s的额外流量持续几分钟到几十分钟，具体时长取决于数据量。
为什么说”短时”而不是”一直”
再平衡过程有明确的生命周期：触发、迁移、收敛，迁移阶段是带宽消耗的高峰，一旦分片分布达到目标状态，流量立即回落，正常情况下，一次性扩容触发的再平衡，在半小时到两小时内完成，具体取决于数据规模和节点数量。
扩容影响业务吗？带宽占用会持续多久
这是运维人员最关心的问题,答案是：影响程度取决于你的集群架构和迁移策略。
同步迁移 vs 异步迁移
- 同步迁移：源节点发送数据后，必须等目标节点确认写入成功，才会继续下一个分片，这种方式数据一致性高，但网络往返占用明显，业务请求延迟会上升。
- 异步迁移：源节点先把数据放入发送缓冲区，不等确认就继续处理业务，带宽占用相对平缓，但复杂度和一致性风险更高。
多数生产环境采用同步迁移+限速的组合，限速就是给迁移流量设置一个带宽上限，比如上限设定为网卡总带宽的20%，这样业务流量优先通过，迁移流量乖乖排队。
实测场景：200GB数据扩容
假设你有一个6节点的Redis Cluster，总数据量200GB，要扩到12节点，每个源节点需要迁出大约一半的分片，在千兆内网、不限速的情况下，迁移200GB数据大约需要1800秒也就是30分钟，期间网络带宽占用率可能飙到90%以上，业务读写的P99延迟会从1ms涨到5ms左右。
如果限速到网卡带宽的30%，迁移时间会拉长到70分钟以上，但业务延迟几乎无感知，这就是用时间换稳定。
带宽占用是”雪崩”还是”细水长流”
一次性全量迁移是雪崩式,容易打满网络，批量分片迁移是细水长流，每次只搬几个分片，搬完再触发下一批，建议在生产环境里设置迁移并发度为2到3个分片，同时开启动态限速，让集群根据实时带宽自动调整迁移速度。
不同扩容场景网络带宽占用对比
扩容不只发生在存储集群,不同系统的再平衡行为差异很大。
云服务器扩容与物理机扩容的带宽差异
云服务器扩容时,数据迁移走的是虚拟网络，云厂商通常会对单台实例的带宽做限制，比如简米云ecs.g7规格实例内网带宽为10Gbps，但突发流量可能被限流，物理机扩容则一般走万兆甚至更高速率的内部网络，带宽上限更高，但交换机端口和机房带宽成本也更高。
在云服务器扩容数据迁移要多久这个问题上，内网带宽是关键瓶颈，同样是1TB数据，10Gbps内网理论上约需800秒，但实际受小文件、协议开销影响，通常需要20到30分钟，如果跨可用区迁移，带宽还要打折扣。
Redis集群扩容代价与Elasticsearch扩容对比
Redis集群扩容代价
主要体现在全量数据同步和槽位迁移，Redis Cluster使用异步复制，主节点在迁移槽位时，会fork子进程生成RDB快照，快照传输占带宽，同时主线程还要处理写命令，内存和CPU压力也上来。
Elasticsearch扩容则依赖分片分配机制,新节点加入后，master节点会自动把部分分片从旧节点搬到新节点，ES支持配置cluster.routing.allocation.node_concurrent_recoveries控制并发度，默认是2，如果集群中有大量分片，带宽占用会持续较长时间，但ES的限速参数设置起来很灵活。
本地磁盘扩容与分布式存储扩容
本地磁盘扩容（比如给单机加硬盘）不涉及网络，只需做数据重分布，而分布式存储（如Ceph、HDFS）扩容必走网络，且数据副本数越多，迁移流量越大，Ceph默认三副本，扩容时每个PG要搬迁的数据量是原始数据的三倍，带宽消耗自然更猛。
怎么解决扩容时数据再平衡的带宽占用
解决方案不是让带宽不占,而是让它占得聪明一点，这里给出一套可直接落地的操作路径。
在迁移前评估现有带宽水位
先用命令查当前网卡流量,Linux下执行nload或iftop，观察业务峰值时段的带宽使用率，如果日常已经用了80%，那就必须限速迁移，否则再平衡流量一来，业务直接超时。
设置合理的带宽限速参数
- Redis Cluster：迁移槽位时没有直接的限速参数，但可以通过
migrate命令的COUNT参数控制批量大小，或者用redis-cli --cluster reshard时指定--timeout和--pipeline来间接影响速度。 - Elasticsearch：设置
indices.recovery.max_bytes_per_sec，默认40mb，可以直接改小到20mb，降低带宽峰值。 - Ceph：
osd_max_backfills控制每个OSD同时参与的backfill任务数，默认1，可以临时设为
2
，但要注意磁盘IO压力。
使用时间窗口躲开业务高峰
把再平衡任务放到凌晨2点到6点执行，这是绝大多数应用的低谷期，通过cron或运维平台定时触发扩容脚本，自动执行迁移，如果业务是7×24小时在线，则优先选择限速加低并发。
分批次扩容而不是一次性加满
比如原来6节点要扩到12节点,不要一次性加入6个新节点。先加2个，等数平衡和带宽回落，再加2个，每批次之间间隔至少观察10分钟，确认集群状态健康再继续，这能显著降低单一时间点的带宽压力。
集群扩容数据再平衡常见问题
扩容时网络带宽被占满，业务超时怎么办
立即暂停再平衡任务,Redis Cluster执行CLUSTER SETSLOT迁移时可以中断，ES可以执行curl -X PUT设置indices.recovery.max_bytes_per_sec为极低值，Ceph可以ceph osd set no-backfill，随后检查业务流量，确认恢复后再调低迁移并发度和速度，分小批次执行。
数据再平衡会不会影响数据安全性
不会,无论是Redis的RDB快照迁移，还是ES的分片恢复，源节点在迁移期间对数据只是读操作，不会删除或修改，只有目标节点确认完整接收后，源节点才会清理对应分片，迁移失败时，集群会保留原分片并重试。
跨地域集群扩容和同机房扩容用的限速策略一样吗
不一样,跨地域集群的专线带宽相对有限，且延迟更高，同机房扩容带宽大、延迟低，可以接受较大并发，跨地域必须把限速调得更低，比如indices.recovery.max_bytes_per_sec设为10mb，并发度设为1，否则很容易打满专线，影响跨区域正常业务。
回到开头那句话：集群扩容时的数据再平衡会短时占用网络带宽，但这是可控的，与其担心带宽被占，不如提前做好评估，用限速、分批次、时间窗口这三板斧，让扩容这个高难度动作平稳落地。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637811.html
