集群扩容是什么
Kafka 扩容分三步：新节点以唯一的 broker.id 加入集群；用分区重分配工具把存量分区迁移过去；确认 ISR 收敛、磁盘与网络水位正常后取消限速。关键认知是——仅增加机器不会自动均衡数据，新节点只会承担新建主题的分区，存量分区的副本仍留在老节点上。
基本信息
| 新节点配置 | 唯一 broker.id、独立 log.dirs、一致的分区/副本相关配置 |
|---|---|
| 集群发现 | ZooKeeper 模式下 zookeeper.connect 一致；KRaft 模式下需按版本方式把新节点纳入控制器仲裁 |
| 迁移工具 | kafka-reassign-partitions.sh，含 --generate、--execute、--verify 三个阶段 |
| 限速参数 | --throttle 指定迁移带宽上限，配合副本限流配置 |
| 观察指标 | 未同步副本数、迁移中的分区进度、节点磁盘与网络水位 |
典型使用场景
- 容量不足：磁盘接近写满或 CPU 长期高位，需要横向加节点
- 吞吐瓶颈：单节点网络或磁盘成为瓶颈，通过分散负载缓解
- 机房调整：新机架或新机器上线后，把部分副本迁过去改善容灾
- 下线替换：老机器要退役，先把其上的分区迁走再摘除节点
- 故障后重建：节点恢复后重新承接原有分区分布
生成并执行重分配
生成并执行重分配
# 1) 指定要迁移的主题与目标 broker 列表，生成重分配方案
cat > topics.json <<'EOF'
{"topics": [{"topic": "prod.order.created.v1"}], "version": 1}
EOF
kafka-reassign-partitions.sh --bootstrap-server kafka1:9092 \
--topics-to-move-json-file topics.json \
--broker-list "1,2,3,4" --generate > plan.json
# 2) 限速执行：带宽预算按集群空闲能力设定，避免迁移影响在线读写
kafka-reassign-partitions.sh --bootstrap-server kafka1:9092 \
--reassignment-json-file plan.json --throttle 104857600 --execute
# 3) 验证进度与结果，确认完成后取消限速
kafka-reassign-partitions.sh --bootstrap-server kafka1:9092 \
--reassignment-json-file plan.json --verify观察与收尾
观察与收尾
# 查看未同步副本与分区分布是否均衡
kafka-topics.sh --bootstrap-server kafka1:9092 --describe --under-replicated-partitions
kafka-topics.sh --bootstrap-server kafka1:9092 --describe | awk '{print $8}' | sort | uniq -c
# 迁移完成后确认限流配置已移除，否则后续复制仍被限速
kafka-configs.sh --bootstrap-server kafka1:9092 \
--entity-type brokers --entity-name 4 --describe | grep -i throttled扩容阶段检查
| 阶段 | 检查项 | 异常表现 |
|---|---|---|
| 加入 | 新节点出现在 broker 列表且 broker.id 唯一 | id 重复会导致节点被拒绝注册 |
| 迁移 | 分区副本逐个完成迁移 | 长时间卡在进度不动，多为限流过严或磁盘不足 |
| 验证 | 未同步副本收敛为 0 | 持续非 0 说明副本同步受阻 |
| 收尾 | 移除迁移限流配置 | 忘记移除会长期限制正常复制速率 |
扩容不会改变已有主题的副本分布：不显式执行重分配，新节点只是闲置。迁移要选在业务低峰，因为迁移期间老节点仍要读出全量数据，磁盘与网络压力是叠加的。