当前位置：首页 > news >正文

Kafka 集群扩容后 Partition 分配不均如何重新平衡负载？

news 2026/5/28 17:56:01

Kafka 集群增加 Broker 后，原有的 Partition 不会自动迁移到新节点，最推荐的做法是使用官方提供的 kafka-reassign-partitions 工具手动执行重分配，适用于生产环境需要均衡磁盘和网络负载的场景。

先说结论：扩容后负载不均是正常现象，需手动触发 Partition 重分配才能利用新 Broker 资源，操作期间务必设置限流以防影响线上业务。

先定位：确认哪些 Topic 的 Partition 集中在旧 Broker 上，评估数据移动量。
先做：生成重分配计划并设置限流值，避免磁盘和网络 IO 打满。
再验证：确认重分配任务状态为完成，且集群监控指标恢复正常。

命令速用版

# 1. 生成重分配计划（将指定 Topic 迁移到目标 Broker 列表）
bin/kafka-reassign-partitions.sh `--bootstrap-server` <host:port> \`--topics-to-move-json-file` topics.json \`--broker-list` "1,2,3" `--generate`# 2. 执行重分配（务必添加 `--throttle` 限制复制带宽）
bin/kafka-reassign-partitions.sh `--bootstrap-server` <host:port> \`--reassignment-json-file` reassignment.json \`--execute` `--throttle` 50000000# 3. 验证重分配进度
bin/kafka-reassign-partitions.sh `--bootstrap-server` <host:port> \`--reassignment-json-file` reassignment.json `--verify`

为什么会这样

Kafka 的 Partition 分配策略是在 Topic 创建时确定的。当你向集群中添加新 Broker 时，Kafka 不会自动移动现有的 Partition 到新节点，新 Broker 默认只承载新创建的 Topic。这意味着旧 Topic 的流量依然全部压在旧 Broker 上，导致扩容后旧节点磁盘或网络带宽率先达到瓶颈，而新节点空闲。

要改变这种状态，必须手动触发 Partition Reassignment 过程，将部分 Partition 的 Leader 和副本迁移到新 Broker 上。这个过程本质上是数据复制，会产生额外的网络传输和磁盘 IO，因此需要谨慎控制速度。

分步处理

1. 准备迁移清单

首先需要确定哪些 Topic 需要迁移。你可以手动编写一个 JSON 文件，列出 Topic 名称，或者使用脚本生成。例如 topics.json 内容如下：

{"topics": [{"topic": "order_topic"}], "version": 1}

2. 生成重分配计划

使用 `--generate` 参数让工具自动计算分配方案。工具会尝试将列出的 Topic 均匀分布到 `--broker-list` 指定的 Broker ID 列表中。执行后会产生一个大的 JSON 输出，将其保存为 reassignment.json。

生成的 reassignment.json 结构示例如下：

{"version": 1,"partitions": [{"topic": "order_topic","partition": 0,"replicas": [1, 2, 3]},{"topic": "order_topic","partition": 1,"replicas": [2, 3, 1]}]
}

3. 设置限流并执行

这是最关键的一步。在生产环境执行 `--execute` 时，必须加上 `--throttle` 参数。该参数限制了复制 follower 的网络带宽（单位字节/秒）。如果不设置，数据迁移可能会占满集群带宽，导致生产消费延迟飙升。具体限流值需根据当前集群空闲带宽估算，建议设置为 50MB/s (50000000) 至 100MB/s，根据集群空闲带宽调整。

4. 移除限流

重分配完成后，务必再次运行执行命令，但去掉 `--throttle` 参数，否则后续的正常副本同步也会受到限制。再次运行相同的 `--execute` 命令，但不添加 `--throttle` 参数即可清除限制。