Kafka 集群扩容与再平衡：从分区迁移到 Leader 均衡

Kafka 集群扩容后新 Broker 无负载、数据分布不均的根本原因是：Kafka 只在创建 Topic 时分配分区副本到各 Broker，扩容后不会自动迁移已有分区。解决这个问题需要执行两步法——先完成副本迁移（Partition Reassignment），再执行 Leader 再均衡（Preferred Leader Election）。操作顺序不能颠倒，否则可能出现所有 Leader 集中在少数 Broker 上的热点问题。

扩容前的准备与评估

扩容前需要确认三件事。第一，新 Broker 的 broker.id、log.dirs、网络带宽是否与现有节点一致。如果新节点磁盘更小或网络更慢，后续分区迁移可能触发 OOM 或长时间同步。第二，检查当前集群的副本因子分布——用 kafka-topics.sh --describe 逐 Topic 查看，确认是否有 Topic 的分区已经集中在少数 Broker 上。第三，评估当前集群负载：通过 JMX 采集每个 Broker 的 MessagesInPerSec、BytesInPerSec、LogEndOffset 指标，确认现有节点是否已接近磁盘或带宽上限。

一个常见误区是在业务高峰期执行扩容。分区重分配会触发大量数据复制，占用 Broker 间网络带宽，可能拉高生产端延迟 10-50 倍。建议在凌晨低峰期操作，或者如果业务允许，分批扩容——先加 1-2 个 Broker 做小范围验证，确认带宽和磁盘 IO 影响在可接受范围内后再全量执行。

第一步：副本迁移（Partition Reassignment）

副本迁移的核心工具是 kafka-reassign-partitions.sh。操作分为三步：生成迁移计划、执行迁移、验证结果。

生成迁移计划时，generate 子命令会自动计算将哪些分区从哪些 Broker 迁移到新 Broker 上。但默认生成的计划可能不够精细——它不会考虑各 Broker 的磁盘使用量均衡，也不会避开高负载 Broker。因此建议只用 generate 生成初始方案，然后手动调整 JSON 配置文件，确保每个分区的目标副本分布在磁盘使用量最低的 Broker 上。

执行迁移时，最关键的一个参数是 --throttle。这个参数限制迁移过程中的副本同步带宽（单位是 bytes/sec）。如果不设置，默认不限速，迁移流量会挤占正常生产流量。根据经验，建议将 throttle 设置为 Broker 间网络总带宽的 30%-50%。比如万兆网卡（约 1.2GB/s），设置 throttle 为 400MB/s 是一个安全起点。迁移过程中可以通过 JMX 监控 ReplicaManager underReplicatedPartitions 指标，如果该值持续大于 0 且不断增加，说明迁移速度过快，需要降低 throttle。

验证迁移结果时，执行完成后不要立即认为万事大吉。用 kafka-topics.sh --verify 检查所有分区是否都已迁移完成，再用 --describe 确认副本分布符合预期。常见问题包括：某个分区卡在迁移中——通常是因为目标 Broker 磁盘满或网络不通；或者分区副本因子在迁移过程中变成了 0——这说明迁移计划有误，需要回滚后重新生成。

第二步：Leader 再均衡（Preferred Leader Election）

副本迁移完成后，所有新增的副本只是 follower 角色。需要执行 Preferred Leader Election 让分区 Leader 均匀分布在所有 Broker 上。

从 Kafka 2.4 开始，auto.leader.rebalance.enable 默认为 true，集群会自动触发 Leader 再均衡。但自动均衡的触发阈值和间隔不一定适合所有场景。如果你的集群 Topic 数量在千级别以上，自动均衡可能导致大量 Leader 切换在短时间内发生，引起客户端频繁重连。因此生产环境建议将 auto.leader.rebalance.enable 设为 false，改为手动在低峰期执行：

kafka-leader-election.sh --election-type preferred --all-topic-partitions

如果不想一次性全量切 Leader，可以用 --topic 参数逐 Topic 执行，或者用 kafka-preferred-replica-election.sh 配合 JSON 文件指定分区列表。

执行 Leader 再均衡前务必确认：当前集群没有正在进行的副本迁移，Under Replicated Partitions 指标为 0，ISR 列表正常。否则在 Leader 切换过程中，如果 follower 落后太多，可能出现短暂的消费中断。

回滚方案

任何线上操作都需要回滚预案。副本迁移的回滚相对简单——将迁移计划中的 broker-to-move-to 改回原来的 Broker 列表，重新执行 kafka-reassign-partitions.sh --execute，数据会自动从新 Broker 复制回原 Broker。但要注意，回滚本身也是一次完整的数据迁移，同样需要设置 throttle 限制带宽。

如果执行过程中发现新 Broker 有问题（比如磁盘故障），更安全的做法是先将该 Broker 从集群中移除（kafka-server-stop.sh 停止进程，然后在 AdminClient 中 remove-broker），等替换硬件后再重新执行扩容流程。

运维建议与产品能力

在实际的集群管理中，分区再平衡是一个高频但容易出错的操作。建议将整个流程脚本化，纳入运维平台统一管理。EasyMR 提供了 Kafka 集群运维管理能力，可以可视化监控副本分布和 Leader 分布状态，降低手动操作的风险。

最后给出几条实战经验：迁移前先对核心 Topic 做一次备份（导出最新 offset 和 consumer group 信息）；每次迁移后观察至少 2 小时的消费延迟变化再做下一步操作；将 throttle、迁移超时时间等关键参数写入运维手册，避免不同人操作时参数不一致。