接了一个Kafka集群的扩容任务三节点扩到五节点要新增两台Broker还得把积压了几个月的旧数据做分区迁移。这套流程走下来踩了不少坑也把整个扩容链路摸透了。这篇文章就把新增Broker节点和数据迁移这件事从头到尾捋一遍包括为什么要迁移、怎么算容量、配置有哪些关键参数、reassign脚本怎么用、限流怎么给、迁移完了还有什么收尾工作要做。这篇内容适合两类人一类是刚接手Kafka集群、准备扩容但不知道从哪下手的运维和开发另一类是已经跑过扩容、但想知道分区分配和迁移原理、想把整个过程做得更稳的人。文章里所有命令和参数都基于Kafka 3.x版本用的是ZooKeeper模式如果你们已经切到KRaft模式个别命令参数会不同我会在对应的位置单独说明。1. 扩容前的准备工作先搞清楚你要解决什么问题1.1 扩容不等于加机器先定位瓶颈再动手很多人一看到Kafka集群压力大第一反应就是加Broker。但扩容这件事最忌讳的就是没搞清楚瓶颈在哪儿就盲目加机器。Kafka的瓶颈通常分几类磁盘空间不够、磁盘IO打满、网络带宽跑满、CPU使用率高、分区数过多导致ZK压力大。这些问题表现相似但解法完全不同。磁盘不够用加Broker确实能缓解但如果你只是单主题流量特别大、分区数又少加Broker意义反而有限——你需要的可能是增加分区或者调整生产者侧的批量策略。我这次接手的集群症状是磁盘使用率接近85%部分热点Broker的IO等待时间明显偏高同时新创建的主题分区分配也不均匀。三台Broker其中两台磁盘快满了第三台相对空闲。这种情况下扩容就很明确加两台机器把旧Broker上的分区副本迁一部分到新Broker上同时让后建的主题天然分布到更多节点上磁盘压力自然就摊开了。所以动手之前我建议你先花半天时间做一次现状盘点每个Broker的磁盘使用量、每个主题的分区数和副本分布、生产端的写入速率峰值、消费端的拉取延迟。这些数据决定了你扩容方案怎么设计。Kafka自身提供的kafka-log-dirs.sh脚本可以看到每个Broker上各主题分区的日志占用情况这个脚本在扩容量化时特别好用。1.2 容量速算模型你到底需要多少台新Broker确定要加几台Broker不能拍脑袋。我给一个自己常用的速算模型实测下来挺实用。假设你单台Broker每天的日志增量是D GB日志保留时间是R天副本因子是F。那单台Broker上数据占用大约是单Broker数据占用 ≈ D × R × F 系统预留(建议至少20%)注意这里的F是副本因子不是Broker数量。比如副本因子3意味着每条消息在集群里存3份每个Broker都保存自己负责的那部分分区的完整数据。实际分配时每个分区副本会落在不同的Broker上所以计算总集群容量时直接用总写入量乘以保留天数再乘以副本因子就行。举个例子集群日均总写入量是500GB保留7天副本因子3那总数据量就是500×7×310500GB约10.2TB。三台Broker每台平均要放3.4TB。如果你给每台Broker挂的盘是4TB容量利用率已经到85%再加点波动就要报警了。这时候扩两台同等规格的Broker单台数据量降到大约2.1TB利用率回到50%出头留出了充足的缓冲空间。还有个细节容易被忽略Kafka的磁盘占用不只是日志数据。__consumer_offsets这个内部主题用来存消费位点也会占用少量空间配置了SSL或SASL的集群还有认证日志但这些占比很小一般不用单独算。不过如果你开了compact模式的内部主题注意一下它的segment数量个别情况下能占掉几百MB甚至几个GB。1.3 开工前的环境确认清单扩容不是把包装上一键启动就完事的。下面这些项我每次都会先确认任何一个没核对清楚都可能让扩容过程翻车。第一版本一致性。Kafka Broker端小版本差异虽然通常兼容但生产环境我强烈建议新节点用和现有集群完全一致的版本。混用版本会带来协议差异极少数情况下会出现消费者rebalance异常或Producer报版本不支持的错。可以先用kafka-broker-api-versions.sh验证一下新旧Broker的协议兼容性。第二确认集群用ZooKeeper还是KRaft模式。3.x版本里很多集群还在用ZK模式但4.x开始KRaft成为主流。两种模式的新增Broker步骤在server.properties配置上不一样ZK模式要配zookeeper.connectKRaft模式不需要ZK而是通过格式化storage目录并配置controller.quorum.voters来加入集群。如果你们还在ZK模式那还要额外确认ZK集群的健康状态——ZK压力过大时扩容Broker会放大问题。第三磁盘类型和挂载方式尽量保持一致。如果旧Broker都是SSD新Broker买了HDD那扩容后热点数据一旦迁到HDD上读写延迟直接一个量级。Kafka不强制要求磁盘一致但混合磁盘会让负载分布变得难以预测对消息延迟敏感的业务影响很大。第四确认监控系统能覆盖新节点。我见过扩容完才发现监控没接新Broker的指标全看不到出了问题连排查方向都没有。扩容前先把JMX exporter或者其它采集agent在新节点上配好让新Broker一上线就能进入监控范围。2. 新增Broker节点配置、启动与线上验证2.1 server.properties关键参数怎么配新Broker的配置文件可以直接复制现有节点的但有几个参数一定要改。broker.id是必须改的且集群内不能重复。我在实际工作中遇到过一次broker.id重复的情况新机器忘记改启动时ZK里发现id冲突直接报错退出。Kafka对broker.id的检查是启动时强制的不会让你带病上线。listeners要显式配置尤其是多网卡机器。有些环境默认绑定了内网IP但如果机器有多个网卡或者你需要外部访问必须明确写好。我习惯写成PLAINTEXT://内网IP:9092这种形式避免出现advertised.listeners和实际不符的问题。log.dirs建议指向一块独立的大容量磁盘。这块区域就是Kafka存放数据的地方不要让日志和操作系统共用一块盘。如果新节点有多块盘log.dirs可以配多个路径用逗号分隔Kafka会自动把分区均衡分配到各个目录这点比单目录扩容省心得多。还有几个全局参数虽然不改大概率也能启动但建议在扩容时一并检查num.partitions默认是1生产环境通常会改大、default.replication.factor这个参数对自动创建的主题生效生产建议设成2或3、offsets.topic.replication.factor内部消费位点主题的副本因子如果设成1挂一台Broker整个集群消费位点就可能丢失这个参数必须在集群创建前设置好而且不能随意调小。如果你之前没注意过这几个参数扩容的时候正好审视一遍。2.2 启动流程先把新节点跑起来再说配置写好后启动本身很简单bin/kafka-server-start.sh -daemon config/server.properties启动后别急着走人做三件验证用jps看一下Kafka进程是否存活进程名是Kafka不是别的。然后用kafka-broker-api-versions.sh --bootstrap-server 新节点IP:9092确认Broker能正常响应请求。最后看一眼server.log里有没有报错比如磁盘目录权限不足、无法加入ISR这类日志。一个常见的坑是新Broker启动后不会立刻自动同步旧数据这是正常的。Kafka不会因为有了新节点就把已有分区分分复制过来新Broker只是注册到了集群元数据里后续创建的新主题分区会把它纳入分配候选旧数据仍然留在原来的Broker上。所以启动完成后集群层面看负载并没有明显变化真正让新Broker出力的是后面第3章的数据迁移。2.3 为什么新Broker一上线就会自动分担新主题流量这是很多人没搞明白的一个点。Kafka创建主题分配分区时默认用的策略是把分区依次轮询到各Broker上。假设原来3个Broker新增到5个之后新建一个6分区的主题分区会按顺序分到5个Broker上新Broker自然分到至少1个分区多的时候分到2个。所以新节点确实会自动承接一部分新业务流量。但这只是“新创建的主题”。存量主题的分区分副本分配在创建那一刻就固定了除非手动执行reassign否则永远不会自动搬到新Broker上。这正好解释了为什么扩容完不迁移新Broker的磁盘占用始终很低而老Broker继续顶着压力。所以数据迁移这件事看起来是可选步骤实际上才是扩容真正的核心动作。关于分区分配策略有个细节值得说新版Kafka里默认的分配器对机架感知做了优化如果你的集群配置了rack信息新分区会尽量分散到不同机架或可用区这样容灾性更好但代价是迁移计划生成时也会考虑机架约束后面看reassign生成的json文件时别觉得它绕。3. 数据迁移实战让旧数据“搬搬家”到新Broker3.1 先分清迁移的两种类型副本迁移 vs 分区迁移数据迁移在Kafka里其实分两种场景很多人混为一谈。第一种是副本迁移。比如某个分区有3个副本其中2个在旧Broker上、1个在新Broker上你想让新Broker分担一点副本数把其中一个旧Broker上的副本挪到新Broker上。这种情况副本总数不变只是位置变了。第二种是分区迁移。比如一个主题的分区有12个但全部或者大部分落在旧Broker上你想让其中几个分区的所有副本腾挪到新Broker上。通过调整分区的目标Broker位置实现负载再平衡。实际操作中你往往是通过一条reassign命令同时完成这两种操作reassign脚本接受一个JSON描述的迁移计划你可以指定每个分区的新副本列表。只要副本列表和原来不完全一样Kafka就会按需执行副本复制、追赶、然后切换。所以迁移的核心工具就是kafka-reassign-partitions.sh。3.2 迁移的完整操作流程从生成计划到验证收尾先说一次性把某个主题全量迁移到新Broker的方法。假设我要迁移的主题叫order_events有12个分区目标是把其中4个分区移到新Broker上。第一步生成迁移计划。用脚本自动生成建议方案bin/kafka-reassign-partitions.sh --bootstrap-server old-broker:9092 \ --topics-to-move-json-file topics.json \ --broker-list 1,2,3,4,5 \ --generatetopics.json的内容大概是{topics:[{topic:order_events}],version:1}--generate会根据当前分区分布和指定的broker列表1到5生成两个JSON一个是建议的新分区分配方案一个是包含了迁移任务的计划。脚本会把这两个JSON都打印出来你需要把第二个“迁移计划”保存成文件比如reassignment.json。注意--generate给出的只是“建议”它尽量让各Broker上的分区数均匀但如果你有特殊诉求比如想让某些分区只落在特定Broker上完全可以手写这个JSON。第二步执行迁移bin/kafka-reassign-partitions.sh --bootstrap-server old-broker:9092 \ --reassignment-json-file reassignment.json \ --execute执行后脚本会返回每个分区的当前副本列表和目标副本列表。这时候Kafka会在后台开始复制数据不会阻塞消息读写。但如果你的分区数据量很大比如单个分区上百GB复制过程会持续比较长时间期间会产生大量网络和磁盘IO。第三步查看进度。用--verify参数轮询bin/kafka-reassign-partitions.sh --bootstrap-server old-broker:9092 \ --reassignment-json-file reassignment.json \ --verify当所有分区都显示reassignment completed时迁移才算真正结束。这里提醒一句--verify只在迁移进行时和刚结束时输出详细状态如果你在迁移完成后很久再跑可能看到的是“there is no ongoing replication of partitions”之类的提示这其实是正常状态。我还习惯在迁移后做一层业务验证选一个迁移过的主题用生产者发一条测试消息再让消费者拉一次确认生产和消费都正常。这一步虽然简单但能尽早发现配置问题。3.3 限流参数必须给否则你可能直接打挂业务这是我认为扩容实战里最容易被忽略、也是后果最严重的一步。reassign执行时Kafka会在Broker之间复制分区的数据文件这个复制过程是走网络和磁盘IO的。如果你迁移的数据量大又不限制复制速度Broker可能会在业务高峰时IO被打满生产者和消费者都遭殃消息延迟飙升甚至触发消费者rebalance。我的做法是在执行reassign时用--throttle参数给迁移限流。这个参数的单位是字节每秒含义是每个Broker参与复制时的最大传输速率注意是per-broker不是集群总体。比如设成50MB/s就是每个Broker最多50MB/s。限流值怎么给我一般先看集群日常总写入量。假设业务高峰期集群写入速率是80MB/s磁盘和网卡都还有余量那我迁移限流可以给30到50MB/s留一半以上的余量给业务流量。如果迁移的数据总量很大比如1TB按50MB/s算也需要5个多小时这种情况我建议把迁移安排在低峰期晚上执行或者分主题分批次迁移避免一次拖太久。具体命令在--execute里加参数bin/kafka-reassign-partitions.sh --bootstrap-server old-broker:9092 \ --reassignment-json-file reassignment.json \ --execute \ --throttle 5000000050MB/s对应50000000字节/秒这个数字可以根据你的机器配置调整。迁移完成后记得把限流去掉。去掉限流不需要重新跑reassign而是执行bin/kafka-reassign-partitions.sh --bootstrap-server old-broker:9092 \ --reassignment-json-file reassignment.json \ --throttle 0--throttle 0就是解除限流。这一步很多人会忘结果就是集群一直维持着较低的传输速率后续新主题复制副本或者副本补充的时候也跟着慢。我吃过这个亏所以现在凡是执行过限流迁移收尾前必查一遍。3.4 迁移收尾别忘了优先副本选举迁移完成后还有一个隐藏问题Kafka的Leader选举是“自动”的但不是“立即”的。分区迁移完成后分区的Leader可能还停留在旧Broker上而新Broker上的副本虽然已经是ISR成员却并不一定被选为Leader。Kafka的默认机制是如果当前Leader broker不在了才会触发选举如果Leader还活着即使已经有更高优先级的副本preferred replica也不一定会切换。这就是我强烈建议迁移后做一次preferred replica election的原因。它会把每个分区的Leader切换到设定的首选副本上通常是副本列表里的第一个。执行方式bin/kafka-leader-election.sh --bootstrap-server old-broker:9092 \ --election-type preferred \ --topic order_events如果不做这步可能会出现一种尴尬局面数据副本已经均匀分布到5台Broker了但Leader还集中在老Broker上读写流量还是压在老节点上磁盘压力是缓解了请求压力和带宽压力并没有本质改善。Leader切换这个动作成本很低收益却实实在在。4. 常见问题与排查技巧实录4.1 扩容迁移过程中的踩坑清单我把真实操作中遇到的典型问题整理成一张速查表基本覆盖了新Broker接入和迁移阶段的常见故障现象可能原因排查与解决新Broker启动报错退出broker.id冲突或log.dirs目录权限不对检查broker.id是否唯一确认数据目录属主和权限正确新Broker起来后没有分担流量存量分区没有迁移执行reassign迁移需要迁的分区而不是等着它自动平衡reassign执行后进度卡住目标副本一直无法跟上ISR查看Broker日志确认是否有fetch超时临时调大replica.lag.time.max.ms迁移期间消息延迟明显升高限流给太小或没限流立即降低迁移速度必要时暂停reassign等业务低谷再继续迁移完成后Leader仍集中在老节点没有做preferred副本选举执行kafka-leader-election.sh把Leader切到新副本部分分区verify显示missing replicas迁移期间有Broker短暂下线确认所有Broker在线后重新执行reassign等待副本补齐新建主题的分区分配仍然不均用了旧版分区分配器或配置了机架感知检查default.replication.factor和partition.assignment.strategy配置4.2 两个真实翻车现场第一个翻车案例是迁移时限流设太大。当时我图省事想着业务叫“低峰期”直接把限流给到了100MB/s。结果Broker的磁盘是HDD实际写入能力就这么大复制流量一上去磁盘IO直接被打满。业务方反馈消息延迟从几十毫秒涨到几秒我们赶紧把限流降回30MB/s延迟才慢慢恢复。那次经历让我明白限流值不是越大越好要根据磁盘随机写能力、网络带宽和业务流量三者的最小值来定。第二个翻车案例是迁移完忘了取消限流。当时我执行了--throttle 50000000之后随手关掉了终端第二天发现集群里所有副本复制都慢吞吞的新加的Broker上ISR一直不完整。排查了半天最后发现是限流还挂着。从那以后我在所有迁移流程的收尾清单里都加了“确认限流已解除”这一项。4.3 扩容后第一周建议盯紧的监控指标扩容完成不代表万事大吉。新Broker加入后的第一周是风险窗口我建议至少盯这几个指标消息延迟是第一个。这里的延迟指的是生产端到消费端的端到端延迟如果新Broker上有分区而消费者从新Broker拉取消息比老Broker慢说明新节点的网络或者磁盘可能有问题。ISR收缩次数是第二个关键指标。这个指标表示分区副本因为跟不上同步而被踢出ISR集合的次数。扩容迁移期间因为大量复制流量占用带宽ISR收缩偶有发生但如果持续出现要考虑是不是副本同步配置太激进或者新Broker规格跟不上。再有就是Broker CPU和磁盘IO等待时间。新Broker刚加入时数据量少CPU使用率可能很低但迁移开始后磁盘IO会慢慢上去。如果磁盘IO等待长期超过20%说明磁盘可能是瓶颈你需要把部分分区再迁走或者考虑换更快的盘。还有一个很容易被忽略的点新Broker上的__consumer_offsets分区。Kafka的消费位点数据是自动分区的如果新Broker加入后恰好分到了这个内部主题的分区Leader而消费者的流量又大你会发现新Broker的规格并不比老节点差但CPU却异常高。这个时候不要慌确认一下__consumer_offsets分区所在的节点把消费位点相关的分区重新均衡一下就好。4.4 关于可视化工具和AdminClient的一点补充整个扩容和数据迁移过程本质上都是在调用Kafka的AdminClient接口。kafka-reassign-partitions.sh这个脚本底层就是Java AdminClient的alterPartitionReassignments和listPartitionReassignments封装。如果你在写自动化运维脚本也可以直接用AdminClient这些API效果和脚本一样。可视化工具方面Kafka UI以前叫Kafka Drop、Offset Explorer这类工具在做扩容时确实好用尤其是查看分区分布和副本状态比命令行直观得多。但有一点要提醒迁移执行本身我建议还是用官方脚本不要完全依赖可视化工具的迁移功能因为工具版本和Kafka版本如果不匹配生成的分配计划可能不符合你的预期。工具看监控可以动生产数据还是谨慎点。最后想说的几句话扩容这件事说起来就是“加两台机器跑个脚本”但每一次真实操作背后都是对业务流量、磁盘容量、集群稳定性三件事的综合权衡。我个人在实际操作中最大的体会是Kafka的数据迁移从来不是“把文件拷过去”这么简单它涉及副本同步、Leader切换、限流控制这些环环相扣的细节。任何一个环节没做扎实后续业务都要付出代价。如果你准备扩容先把这篇文章里的清单过一遍特别是限流和优先副本选举这两步千万别省。迁移完成后也不要急着拍胸脯说大功告成花一两天观察新Broker的负载曲线确认真正分摊了压力再向团队汇报结果也不迟。