Kafka

Kafka 集群 Broker 节点扩缩容完整操作

·13 分钟阅读·4990 字
Kafka实操高阶场景题
📋 目录

Kafka 集群 Broker 节点扩缩容完整操作

核心概念 Kafka 新增/下线 Broker 不会自动迁移分区，必须使用 kafka-reassign-partitions.sh 手动重分配，全程支持限流不中断。

1. 核心前置原理

  1. Kafka新增/下线Broker不会自动迁移分区副本，新节点空负载、待下线节点会残留分区，必须使用 kafka-reassign-partitions.sh 手动重分配；
  2. 分区迁移必须两步生成JSON方案：topics清单JSON → 生成分配计划JSON，先预览校验再执行，防止集群IO风暴、副本同机丢数据；
  3. 扩容目标：把存量Topic副本打散到新节点均衡负载；缩容目标：把待下线节点上所有分区全部迁出，无残留后再停机；
  4. 全程支持限流，业务低峰操作，不中断生产消费、零消息丢失。

2. 集群扩容（新增Broker节点）完整流程

场景：现有broker.id=1、2、3，新增节点broker.id=4

2.1. 步骤1：新节点配置、启动并加入集群

  1. 修改server.properties核心配置（id全局唯一，不可重复）
broker.id=4
listeners=PLAINTEXT://0.0.0.0:9092
log.dirs=/data/kafka-logs
zookeeper.connect=zk1:2181,zk2:2181,zk3:2181
# KRaft集群替换为controller.quorum.bootstrap.servers
  1. 后台启动kafka
bin/kafka-server-start.sh -daemon config/server.properties
  1. 校验节点成功加入集群
# 查看集群全部broker列表，能看到4即加入成功
bin/kafka-broker-api-versions.sh --bootstrap-server 1:9092

重点：此时节点4无任何分区，完全空闲，扩容只完成一半，必须迁移分区均衡负载。

2.2. 步骤2：生成迁移JSON方案（两步JSON机制）

2.2.1. ① 编写待迁移Topic清单 topics-to-move.json

定义需要打散扩容的业务Topic，工具读取此文件确定迁移范围

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

2.2.2. ② —generate 生成正式分区分配计划 reassignment.json

指定全部集群broker列表（包含新节点4），工具自动计算均衡副本分布，输出完整迁移方案

bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--topics-to-move-json-file topics-to-move.json \
--broker-list "1,2,3,4" \
--generate > reassignment.json

输出的reassignment.json精确记录每个分区、每一份副本分配到哪些broker，可手动编辑优化：

  • 规避副本落在同一机架/同一机器；
  • 热点分区优先分配到SSD高速新节点；
  • 拆分分批迁移，控制单次同步流量。

2.3. 步骤3：执行分区迁移，同步副本到新节点

增加--throttle限流，限制同步带宽，避免抢占业务IO（示例10MB/s）

bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--reassignment-json-file reassignment.json \
--execute \
--throttle 10485760

后台自动同步副本：新broker4成为follower，完整同步分区日志加入ISR，旧节点副本保留至迁移完成。

2.4. 步骤4：校验迁移全部完成

bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--reassignment-json-file reassignment.json \
--verify

输出completed successfully代表所有分区同步完毕；可查看Topic分区分布，确认副本均匀分布到1/2/3/4四个节点。

2.5. 步骤5：扩容收尾优化

  1. 清除限流：迁移完成后取消带宽限制，恢复正常副本同步速度
bin/kafka-reassign-partitions.sh --bootstrap-server 1:9092 --verify --throttle -1
  1. 新创建Topic自动均衡：后续新建topic会自动分配到全部4台broker。

3. 集群缩容（安全下线Broker节点）完整流程

场景：集群broker.id=1、2、3、4，下线broker.id=4，最终保留1、2、3

3.1. 核心红线：严禁直接停机节点

直接下线会导致该节点上所有分区副本缺失，集群进入非健康状态、读写报错、数据丢失风险；必须先把节点4上所有分区全部迁出，无任何残留分区再停机。

3.2. 步骤1：生成缩容迁移JSON方案

3.2.1. ① 编写topics-to-move.json（所有业务topic清单）

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

3.2.2. ② generate生成缩容分配计划

--broker-list只填写最终保留的节点1,2,3，工具自动将所有分区从broker4迁出

bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--topics-to-move-json-file topics-to-move.json \
--broker-list "1,2,3" \
--generate > shrink.json

打开shrink.json可校验：所有partition的replicas数组中无4，副本全部迁移至剩余节点。

3.3. 步骤2：执行缩容分区迁移（限流保护业务）

bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--reassignment-json-file shrink.json \
--execute \
--throttle 10485760

迁移逻辑：把broker4上所有副本同步到1/2/3，同步完成后自动删除broker4本地分区日志。

3.4. 步骤3：反复校验迁移完成，节点4无任何分区

  1. 执行verify确认迁移全部完成
bin/kafka-reassign-partitions.sh \
--bootstrap-server 1:9092 \
--reassignment-json-file shrink.json \
--verify
  1. 核查所有topic分区分布，确认broker.id=4不存在任何副本
bin/kafka-topics.sh --bootstrap-server 1:9092 --describe

3.5. 步骤4：优雅下线Broker节点

  1. 取消同步限流
bin/kafka-reassign-partitions.sh --bootstrap-server 1:9092 --verify --throttle -1
  1. 优雅停止kafka进程（禁止kill -9）
bin/kafka-server-stop.sh
# 或 kill -15 进程PID
  1. 校验集群broker列表，4已从集群中移除
bin/kafka-broker-api-versions.sh --bootstrap-server 1:9092

3.6. 多节点缩容规范

一次只下线一台broker，完成全量分区迁移、验证无残留后，再重复流程下线下一台，禁止一次性多台同时缩容。

4. 为什么扩缩容必须先走generate生成两份JSON（结合之前对话总结）

4.1. 两份JSON分工完全独立，缺一不可

  1. topics-to-move.json：输入清单，仅定义需要迁移的Topic范围，不包含分区分配规则；
  2. 生成输出reassignment.json/shrink.json：迁移执行计划书，精确绑定每个分区副本对应的目标broker，是execute阶段唯一执行依据。

4.2. 安全设计：先预览校验，再执行，规避线上重大故障

工具拆分--generate计算、--execute执行两步，依靠JSON做隔离：

  1. generate仅做内存计算，不改动集群任何数据，运维可人工核对副本分布；
  2. 自动生成方案存在缺陷（扩容副本扎堆新节点、缩容副本同机架），可手动编辑JSON修正分配规则；
  3. 确认方案完全符合高可用要求后，才发起跨节点副本同步；
    若跳过JSON预览直接执行，极易出现副本同机、集群IO风暴、分区副本不足引发读写不可用。

4.3. JSON标准化适配运维自动化

  1. 批量管控：JSON数组支持一次性管理数十个Topic，适配脚本批量扩容/缩容；
  2. 变更留痕：迁移方案文件存档，用于故障追溯、运维变更审计；
  3. 可编程处理：Shell/Python脚本解析修改JSON，实现分批迁移、冷热节点分区隔离，纯命令行参数无法精细化控制。

4.4. 工具无自主调度能力

kafka-reassign-partitions.sh仅为执行工具，无法自动分析集群负载、自动规划分区放置，必须依靠结构化JSON文件明确每个分区的目标broker，才能完成副本同步搬迁。

5. 生产扩缩容通用最佳实践&避坑

5.1. 操作时间窗口

全部分区迁移操作放在凌晨业务低峰，集群CPU、磁盘IO占用低于50%执行。

5.2. 限流必开

迁移同步带宽抢占正常生产消费IO，--throttle限制同步速度，迁移完成后关闭限流。

5.3. 分批迁移Topic

集群Topic上千个时，不要一次性全量迁移，拆分多批执行，防止瞬时大量副本同步打满网卡。

5.4. 副本高可用约束

扩容/缩容生成JSON后必须校验：每个分区副本分散在不同机架、不同物理机器，保证单节点宕机不丢失数据。

5.5. 缩容致命禁忌

未迁出节点上所有分区就停机broker，会直接导致对应分区副本数不足，集群状态变黄、生产报错NotEnoughReplicas。

5.6. 监控配套

迁移过程监控指标：磁盘IO、网卡流量、ISR同步状态、集群健康状态，出现延迟暴涨立即降低限流带宽。

5.7. 自动均衡工具补充

大规模集群可使用Cruise Control自动均衡分区，无需手动生成JSON，适合长期负载自动调平；小规模集群仍使用原生reassign脚本可控性更强。

6. 扩缩容完整流程速记

6.1. 扩容

新增节点配置启动加入集群 → 编写topic清单json → generate生成均衡分配json → execute限流迁移 → verify校验完成 → 取消限流

6.2. 缩容

编写topic清单json → generate生成迁出分配json（broker-list不含待下线节点）→ execute限流迁移 → verify确认节点无残留分区 → 优雅停机broker

6.3. 核心统一底层逻辑

无论扩容、缩容、单集群内分区迁移，底层均依赖kafka-reassign-partitions.sh双JSON方案，通过预生成分配计划保障集群数据安全与负载均衡。

返回首页订阅更新