Kafka集群扩容需整体规划，先明确触发条件（如磁盘≥75%、NotEnoughReplicasException等），再精准计算资源（磁盘=日均条数×平均大小×保留天数×副本数×1.1等），严格配置新Broker参数，执行分区重分配，并验证消费者offset、端到端延迟及故障恢复能力。
Kafka集群扩容不是简单加机器，而是要结合资源现状、业务增长和系统稳定性做整体规划。核心在于：先算清楚要扩多少，再决定怎么扩，最后确保扩得稳。
明确扩容触发条件
别等告警才行动，日常监控中出现以下情况就该启动扩容评估：
- 磁盘使用率持续高于75%，尤其单节点接近85%
- 生产者端频繁出现 NotEnoughReplicasException 或 TimeoutException
- 消费者组 lag 持续上升，且无法在保留窗口内追平
- Broker CPU 长期 >70% 或网络出口带宽利用率 >80%
精准计算资源需求
避免“拍脑袋扩容”，用公式支撑决策：
- 磁盘空间 = 日均消息条数 × 平均消息大小 × 保留天数 × 副本数 × 1.1（缓冲）
- 内存估算：每 100 MB/s 吞吐建议分配 1 GB 堆内存，JVM 堆不宜超过 32 GB
- CPU 核心：高吞吐场景建议 ≥8 核，优先保障网络和磁盘 IO 能力
- 网络带宽：需同时满足生产写入 + 副本同步 + 消费拉取三路流量叠加
新增 Broker 的关键配置项
新节点加入前，server.properties 中这几项必须严格校对：
- broker.id：全局唯一，不能与现有节点重复
- listeners 和 advertised.listeners：前者绑定本地地址，后者暴露给客户端的真实地址，内外网分离时尤其注意
- log.dirs：建议挂载多块 SSD 磁盘，用逗号分隔路径，提升 IO 并行度
- zookeeper.connect：指向同一 ZooKeeper 集群，路径后缀（如 /kafka）必须一致
- cluster.id：所有 Broker 必须相同，否则无法识别为同一集群
分区重分配必须做的三件事
新节点上线后不迁移分区，等于没扩容：
- 用 kafka-topics.sh --describe 查当前分区分布，确认热点是否集中
- 用 kafka-reassign-partitions.sh --generate 生成均衡计划，或手动编写 topics-to-move.json
- 执行迁移后，持续观察 UnderReplicatedPartitions 和 IsrShrinking 指标，确保副本同步完成
扩容后验证不可跳过
完成操作不等于成功，必须验证闭环：
- 用 kafka-consumer-groups.sh --describe 确认所有消费者组 offset 正常推进
- 发一批测试消息，验证端到端延迟（P99 ≤ 200ms 为常见基准）
- 检查新 Broker 的 RequestQueueTimeMs 和 NetworkProcessorAvgIdlePercent，确认无瓶颈
- 模拟单点故障（如 kill 一个旧 Broker），验证服务连续性和数据可用性
