先说个场景。我这边有一套跑了将近三年的Kafka集群6台物理机Topic数量一度逼近90个峰值写入每秒十几万条消息。因为机房租约到期要整体搬迁顺便还想把版本从2.5升到3.5把当年分区分布不均的老账一起结了。这种需求放到很多公司都很典型不是集群出了大问题才迁而是机房续约、硬件换代、版本EOL、云厂商切换、甚至容灾整改都会逼着你动那套已经稳定运行很久的消息中枢。Kafka迁移麻烦就麻烦在它不是单纯把数据文件拷过去就行。生产端怎么切、消费端怎么接、副本怎么重新分配、迁移期间消息会不会积压、万一迁到一半出问题怎么回滚这些链条上的每一环都得提前想清楚。网上讲Kafka安装的教程一大堆讲迁移的文档也不少但大多数是从工具命令角度去说缺少一条“从评估到回滚”的完整链路。这篇就基于我做过的集群搬迁和版本升级实操把Kafka迁移这件事从头到尾拆开讲重点覆盖路径选型、迁移前的评估项、分区副本重分配的完整步骤、数据校验与流量切换以及迁移过程中最容易翻车的几个坑。不管是裸机换机房、容器化改造还是云上云下互迁核心思路都能复用。1. 为什么挪Kafka集群比想象中更麻烦很多中间件迁移比如MySQL做到主从同步、切换IP就能解决大半问题。Kafka不一样它是一个“分区-副本”体系数据分散在多台Broker上同一份数据存在多个副本生产者和消费者直接连集群的任意Broker这导致迁移时要同时处理三件事数据本身要搬、副本关系要重建、客户端连接要平滑切换。另外还有一个容易被忽略的点Kafka集群往往承载着大量业务Topic这些Topic背后是不同的团队、不同的重要等级、不同的流量特征。有的Topic每秒写入几十MB有的Topic一天都没几条消息。迁移时如果一刀切地按统一节奏搬低峰期流量小的Topic很顺利高流量Topic则可能因为副本同步跟不上而产生一直迁不完的现象。Kafka迁移失败的后果也比一般服务严重。消息本身就是硬数据丢了很难找回消费端Lag被拉到几千万业务感知到的可能就是“数据延迟一天”更麻烦的是有些消费组在迁移过程中会频繁Rebalance导致消费者反复加入退出延迟和错误消息双双上升。所以迁移这件事第一原则永远是可以先慢但不能出错。我见过不少团队把Kafka迁移纯当成“重启服务加拷贝文件”最后要么是副本数低于预期要么是消费位移错乱要么迁移结束后才发现某个内部Topic还有副本挂在旧Broker上一撤机器就丢数据。这不是工具不行是迁移前没把盘点做透迁移中没把步骤拆细。2. 动手前先回答四个问题迁移路线怎么选2.1 四种常见迁移路径的对比Kafka迁移并没有一个万能方案。根据迁移范围和数据流的关系我把它分成四种实际操作时往往选择其中一种或组合使用。路径一分区副本重分配集群内换机器这是最常用、最平滑的方案适合“旧集群整体换成新机器”或“新增Broker然后下线旧Broker”。它的思路是新Broker先空节点加入现有集群通过 kafka-reassign-partitions 把每个分区的一部分副本搬到新Broker上等数据同步完成后新Broker逐步接管Leader角色最后旧Broker逐个下线。优点是不需要动生产者和消费者的代码数据还在同一个集群内不需要双写不需要外部同步工具。缺点是整个迁移过程依赖集群自身的副本复制对网络带宽、磁盘IO有消耗而且改造范围局限在“同一集群”内。路径二MirrorMaker 2 做跨集群同步适合跨机房容灾、云上云下迁移、大版本跨度升级比如2.x迁到3.x甚至4.x这类场景。MirrorMaker 2 会把源集群的Topic数据、消费组状态、Topic配置同步到目标集群迁移结束后客户端整体切换到新集群。优点是源集群和目标集群完全隔离风险面小缺点是数据是“异步同步”的存在秒级到分钟级的延迟迁移窗口内如果源集群写入了数据目标集群可能还没有完全追上切流时需要控制写入或接受短时丢新数据的可能性通常业务上可以接受一小段停写。路径三双写双读Parallel Consumption生产端同时写两级集群消费端优先读新集群并校验稳定后再摘掉旧集群。这种方式最安全但改造成本最大适合对数据完整性要求极高、且完全无法容忍停机窗口的金融类业务。Kafka迁移很少需要做到这一步因为上面的路径一已经能在保持客户端不变的前提下完成集群替换。路径四冷备迁移停写拷贝小集群、低要求场景先把消息停掉然后直接拷贝磁盘文件到新集群。这个只适合Topic极少、数据量极小、能接受长时间停写的内部实验环境生产环境请直接忽略。三种主路径横向对比我整理如下迁移路径适用场景停机窗口数据风险客户端改造成本复杂度分区副本重分配换机器、换机房、小版本升级几乎为零低无中MirrorMaker 2跨集群、跨机房、大版本升级分钟级可控中异步同步需切换连接信息中高双写双读金融级、零容忍丢数据零极低高高2.2 数据体量和带宽测算迁移前第一件事不是敲命令是搞清楚“集群里到底有多少数据、每天新增多少”。这一步决定了整体时间预期。我当时的测算方法很直接# 查看所有Topic的磁盘占用 du -sh /data/kafka/kafka-logs-* | sort -rh | head -20 # 查看所有Topic的分区总数 kafka-topics.sh --bootstrap-server localhost:9092 --list | wc -l有了总量之后把单位换算成GB再除以期望的同步带宽就能大致得到副本搬完需要的时间假设总数据量1.2TB三个副本全量重分配相当于要复制约2.4TB的数据原有副本保留新增副本复制一份。限流值设为50MB/s基础时间为 2400GB ÷ 50MB/s ≈ 13.7小时。但这不是精确值。实际操作中副本复制和线上实时写入是并行的新拷贝的数据会不断被业务写入覆盖需要反复追赶。我的经验是把理论时间再乘以1.5基本是迁移的合理预期。如果等不了这个时间就把限流调大但这时候要接受业务高峰期带宽被打满的风险。2.3 版本与客户端兼容性这是很多人忽略但在迁移时一定会遇到的坑。Kafka从2.x到3.x经历了很大的协议变化比如2.8版本之后可以完全脱离ZooKeeper、3.x正式引入KRaft模式。如果旧集群是ZooKeeper架构新集群想直接上KRaft客户端兼容性就得格外注意。我处理的方式是先查一次所有客户端的kafka-clients依赖版本确认最低版本不低于服务端支持的最低协议版本。凡是低于2.0的客户端建议先升级依赖再动集群否则迁移完连接不上新集群才是真正的灾难。2.4 迁移预案清单把评估项浓缩成一页纸迁移前逐项打钩[ ] 当前Kafka版本、Topic总数、分区总数、副本因子[ ] 磁盘总占用、单Topic最大占用、每日新增数据量[ ] 高峰写入QPS、消息平均大小、峰值带宽占用[ ] 消费组清单、各组Lag基线值、组长和联系方式[ ] 客户端版本分布、生产者和消费者连接方式域名/IP[ ] 监控面板是否覆盖Broker网络吞吐、磁盘IO、GC耗时、ISR伸缩[ ] 回滚方案旧集群保留时间、DNS切换记录、磁盘不格式化[ ] 迁移时间窗口选业务低峰期且预留至少1.5倍预期时间这张清单看似基础但80%的迁移事故都是因为其中一两项没提前确认比如“原来有个Topic的保留时间被改成7天”“有个消费组根本没人维护但还在跑”。迁移前把这些挖出来后面能省很多事。3. 分区副本重分配同集群内“乾坤大挪移”的完整实操如果你的场景和我一样是“集群整体换机器”或“扩容后缩容旧机器”那我强烈推荐分区副本重分配这条路。这个方案的底层逻辑一句话就能说清让新Broker以空身份加入集群然后靠Kafka自身的副本机制把数据逐步复制到新Broker上等副本同步完成后Ledger自然转移到新机器旧Broker就可以功成身退。3.1 为什么优先选它而不是MirrorMakerMirrorMaker虽然看起来“更正规”但实际操作中要处理两套集群的Topic配置同步、消费组状态同步、客户端切换整个链路长得多。分区副本重分配的本质是“还是在同一个集群里数据没有出借只是换了个物理位置”所以生产者和消费者的连接信息不需要变还是连那一套bootstrap地址不需要保证“源集群-目标集群”的实时一致性问题因为根本不存在第二个集群迁移过程天然支持回滚只要旧Broker不关机下线随时可以把分区迁回去。当然它也有边界如果目标和源是完全独立的两个集群比如跨云厂商那重分配就无从谈起必须回到MirrorMaker。在“换机器不换集群”的场景里它就是最平滑的方案。3.2 新Broker加入集群前的准备工作新Broker对集群来说就是一台“新工人”。加入之前要保证几件事新机器的硬件规格不低于旧机器磁盘建议用吞吐更稳的SSD或NVMe盘server.properties中 broker.id 不得和现有Broker冲突建议从1001开始编号和旧Broker的0、1、2…区分开这样迁移后看分区分布一眼就能知道哪些副本已经搬过去了配置的log.dirs路径、zookeeper.connect或controller.quorum必须和旧集群一致先只启动一台新Broker观察它能否顺利注册成功、是否有分区被自动均衡过去默认配置不会自动迁移所以通常只是加入集群待命。我习惯的做法是一次只加入一台新Broker确认稳定后再加第二台。一次加太多控制器Controller的Leader选举压力会突然上升在高峰期可能引发短暂不可用。3.3 生成分区重分配计划假设现在集群有 0、1、2 三台旧Broker新Broker为 1001、1002、1003。先让三台新Broker全部加入集群且状态正常然后生成一份“把全部分区均匀摊到6台Broker”的计划# 生成迁移JSON重点看v2版本支持 --bootstrap-server kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --generate \ --broker-list 0,1,2,1001,1002,1003 \ --topics-to-move-json-file topics.json \ reassignment.json这里需要一个 topics.json格式长这样{ version: 1, topics: [ {topic: order_events}, {topic: user_action_log} ] }注意这一步生成的是全量重新均匀分配的方案它会把所有Topic的副本从“只在旧三台”改为“分布在六台”。如果你希望控制某些核心Topic不要全部摊开可以手工编辑生成的 reassignment.json把相关分区的 replica 数组只指向指定的三台新Broker。我实际操作时对几个高流量Topic做了手工锁定不为别的就是为了让它们的副本能优先在新机器上集合便于后续单独验证。3.4 分批执行并带上限流生成计划后不要一股脑全量执行。Kafka官方提供的方案是每次最多处理同时移动的分区数大约100到200个分区比较合适。分区数太多的话控制器要一次性给大量副本下发移动指令轻则IO打满重则控制器线程阻塞导致Leader选举延迟。执行时我建议带上限流参数# --throttle 单位是字节/秒这里设置为 50MB/s kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --execute \ --reassignment-json-file reassignment.json \ --throttle 52428800限流参数的作用是限制副本复制的峰值带宽防止迁移把机房带宽吃满导致业务流量抖动。它不影响正常的消息读写吞吐因为正常业务流量走的是磁盘写入路径副本复制是后台任务限流只针对副本复制部分。关于限流值怎么定我自己的估算方式是先看日常Broker峰值带宽比如单Broker峰值占用200MB/s那么全集群限流设在50MB/s留足余量。如果是内网千兆环境限流不建议超过80MB/s万兆环境可以放宽到200MB/s但还是要结合实际负载做微调。3.5 验证与重复执行每执行完一批等它收敛后必须验证kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --verify \ --reassignment-json-file reassignment.json看到所有分区状态变为Reassignment completed才表示这一批搬完了。如果出现Reassignment in progress先别急着执行下一批查一下是哪个分区在拖后腿多数是Topic写入量太大副本一直在追赶业务写入。一批验证完后重复 3.3 到 3.5 直到所有分区都迁到目标Broker上。3.6 千万别跳过内部Topic的重分配这是我第一次做迁移时踩过的坑。重分配计划如果只覆盖了业务Topic那么 __consumer_offsets 这个存放消费位移的内部Topic它的副本还是全部留在旧Broker上。当你下线旧Broker时这个内部Topic的副本数直接跌破1消费者组会集体失联消费位移也会出现读取异常。处理方式很简单在生成迁移计划时把内部Topic也纳入范围。Kafka不允许你直接用kafka-topics.sh --list看到它但reassign的--topics-to-move-json-file里可以把它写进去。例如{ version: 1, topics: [ {topic: order_events}, {topic: __consumer_offsets} ] }操作完之后再把 __consumer_offsets 的分布打出来确认一遍kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic __consumer_offsets正常情况下它的每个分区副本应该均匀落在所有旧Broker和新Broker上。4. 数据校验、流量切换与回滚的细节方式分区副本重分配完成之后直观上数据已经“到”新Broker了但还不能直接下线旧Broker。我在这一步做的校验和切换基本可以分成四个动作。4.1 分区日志大小与Lag双维度校验第一个维度是看分区Leader是否已经转移到新Broker上。因为分区迁过去后Leader不一定立刻切到新的副本上需要主动触发或者等待旧Leader因为某些原因失联。Kafka有一个机制叫优先副本选举我们可以用它把Leader切到新Broker# 对所有已分配的Topic执行优先副本选举 kafka-leader-election.sh \ --bootstrap-server localhost:9092 \ --topic order_events \ --partition 0 \ --election-type preferred第二个维度是看数据是否完整。最直接的做法是对比新旧Broker上分区目录的大小但不是所有分区都能做到字节级一致因为那边可能还留着一些被清理完的历史文件。更可靠的依据是消费组Lagkafka-consumer-groups.sh \ --bootstrap-server localhost:9092 \ --describe --all-groups如果所有消费组的LAG列均为0或迁移前的基线水平说明消息从生产端到消费端整条链路是通的。如果还有消费组Lag异常偏高先排查是数据没搬到还是消费端本来就没跟上不能带着大Lag下线旧集群。4.2 客户端的三种切换方式分区副本重分配的场景下客户端连接方式基本不用大动但新旧Broker节点列表需要平滑切换。实际操作中我见过三种方式方式一DNS域名切换最推荐客户端配置里不写具体Broker IP而是写一个域名比如 kafka.internal.example.com通过DNS解析到各Broker。迁移前把它解析到旧Broker迁移完成后把解析记录切到新Broker客户端重启后自动连接新节点。这种方式回滚也快把DNS记录切回去就行。方式二改bootstrap.servers后滚动重启在代码或配置中心修改bootstrap.servers列表逐个滚动重启生产者和消费者。这种方式需要业务方配合但可以做到客户端无感因为Kafka客户端天然支持Broker列表变化。缺点是如果客户端数量庞大滚动重启耗时很长。方式三独立的连接网关/代理层对客户端隐藏真实Broker地址统一指向一个代理层由代理转发到实际集群。这个方案适合客户端特别多、不方便逐个改配置的团队但因为每个消息都要多一跳延迟会增加还需要单独维护代理高可用除非团队有余力否则不太推荐。4.3 旧Broker下线流程旧Broker的下线一定要稳健我习惯分三步先确认所有业务Topic和内部Topic的副本都已经迁移出旧Broker通过kafka-topics.sh --describe检查任何分区的副本都不再包含待下线Broker的ID用kafka-server-stop.sh或 systemctl 停止旧Broker进程观察集群是否出现异常告警等5到10分钟观察Controller有没有反复选举、ISR有没有收缩、生产端有没有报错确认稳定后再停下一台。一次只停一台不要同时停多台。旧Broker停掉后它的数据盘先保持原样一段时间不要立刻格式化或用于其他用途我通常保留至少3个自然日最多一周。4.4 回滚预案的两种触发条件迁移过程中的回滚与普通发布回滚本质一致只有在新状态出现问题时才回切旧状态。分两种情况迁移过程中出现问题比如某批分区迟迟无法收敛直接取消未完成的迁移任务已经搬过去的分区可以后续再搬回来旧Broker没有下线所以集群本身仍然健康问题不大迁移完成后、新旧切换出现异常比如新Broker频繁GC、消费Lag暴涨通过DNS切回旧Broker列表客户端重启后重新连回旧集群。第二种情况记得先别急着把旧Broker的进程停干净留一台作为回滚入口整体回滚动作控制在10到20分钟内可以完成。5. 迁移中的真实坑位延迟飙升、副本失配与Rebalance风暴5.1 迁移期间消息延迟为什么突然变高这是几乎每次Kafka迁移都会遇到的症状。消息延迟高的表象是消费者看到的Lag在增长生产端感知的写入超时也在增加。其根本原因是副本复制占用大量网络和磁盘IO导致消息落盘和副本确认变慢。我当时观察到一个很典型的现象迁移限流从50MB/s调到80MB/s后整个集群的网络吞吐确实上来了但生产端的producer队列时间从原来的2毫秒涨到了200毫秒。原因是消息确认机制acksall要求所有ISR副本都写入成功而副本复制本身的优先级并不高于正常业务写入在带宽饱和的情况下正常消息写入只能排队等待。解决这个问题的思路不是放弃限流而是把迁移窗口和业务高峰错开同时在限流参数设置上“宁慢勿快”。还有一个细节值得提迁移期间可以把生产端的acks暂时从all降为1减少单个消息等待副本确认的时间但这会带来短时数据丢失风险非必要不要动。5.2 分区副本一直“搬不完”的排查链路有一次我遇到一个Topic迁移计划执行后两小时还挂在in progress状态一直不变。踩过的经验告诉我这时候不能干等按下面的链路排查看副本是否在持续增量同步kafka-reassign-partitions.sh --verify如果一直在跑大概率是数据在追赶实时写入看具体分区的Leader在哪如果Leader还在旧Broker上同步过程会额外消耗一次转发必要时手动触发Preferred Leader Election看限流是否设得太低50MB/s对一个单Topic每秒写入80MB的业务来说永远跑不赢要么提高限流值要么先暂停该Topic的生产流量如果业务允许看网络是不是被其他任务占满当时检查时发现集群同时有另一个数据同步任务加起来已经把带宽打满这才找到根本原因。排查下来最有效的手段其实就是先降低该Topic的写入压力再调高限流让副本复制追上实时数据然后分批完成搬迁。5.3 消费组在迁移过程中频繁Rebalance怎么办分区副本重分配过程中Broker的下线动作会触发分区Leader切换消费者会因为连接断开而触发组内Rebalance。Rebalance本身是正常机制但如果频繁发生会导致消费者成员反复加入退出消费停顿和重复消费并行出现。我碰到的Rebalance风暴大多是session.timeout和heartbeat.interval参数设置太短导致的。在迁移窗口内把消费者的session.timeout.ms从默认的45000调到90000heartbeat.interval.ms从3000调到10000能明显降低这类“假失联”的触发概率。这个改动不需要改代码在启动参数或配置中心临时调整即可迁移完成后改回默认值。5.4 迁移中如何直观判断进度UI工具和监控日常管理Kafka迁移用命令行工具确认状态是基本功但想一目了然地看到副本分布、Leader分布、分区流量建议部署个Web UI。我用过几款简单对比工具项目状态迁移相关的强项不足Kafka UI原kafka-ui活跃分区副本分布直观、支持查看Reassign状态不看限流细节EFAK原Kafka Eagle偏运维向监控项丰富、Lag告警完整界面稍老旧Kafka Manager维护少能看副本和Leader分布新版本适配一般迁移过程中我主要靠Kafka UI看副本是否均匀摊到新Broker上以及每台Broker的流量是否有明显倾斜。眼见为实命令行再准确也代替不了可视化面板对整体局面的判断。5.5 一个小技巧迁移完成后用“平衡状态”验收迁移完成不等于所有分区都均匀分布。Kafka的副本分布在你手动搬迁的过程中往往会留下“有些不均匀”的尾巴比如某些Broker上副本数偏多另一些偏少。条件允许的话迁移完成后再执行一次kafka-reassign-partitions.sh --generate把--broker-list换成只包含新Broker生成一份纯新集群的均衡方案让副本分布回归健康。这一步做完之后集群的运行状态才算真正进入“平稳期”。我在那次迁移后观察了一周消息延迟恢复、消费组Lag稳定、Controller无异常切换整体才敢说迁移成功。回看整个过程Kafka迁移最耗费心力的地方从来不是敲那几条命令而是前期的数据摸底、路径选择、限流节奏和回滚预案。只要这些想清楚了实际操作就是一步步推进的事。 
长河君 · 2026/10/9 6:19:22 · 阅读 1.2k Kafka集群迁移全攻略：从路径选型到回滚的完整实操指南
先说个场景。我这边有一套跑了将近三年的Kafka集群6台物理机Topic数量一度逼近90个峰值写入每秒十几万条消息。因为机房租约到期要整体搬迁顺便还想把版本从2.5升到3.5把当年分区分布不均的老账一起结了。这种需求放到很多公司都很典型不是集群出了大问题才迁而是机房续约、硬件换代、版本EOL、云厂商切换、甚至容灾整改都会逼着你动那套已经稳定运行很久的消息中枢。Kafka迁移麻烦就麻烦在它不是单纯把数据文件拷过去就行。生产端怎么切、消费端怎么接、副本怎么重新分配、迁移期间消息会不会积压、万一迁到一半出问题怎么回滚这些链条上的每一环都得提前想清楚。网上讲Kafka安装的教程一大堆讲迁移的文档也不少但大多数是从工具命令角度去说缺少一条“从评估到回滚”的完整链路。这篇就基于我做过的集群搬迁和版本升级实操把Kafka迁移这件事从头到尾拆开讲重点覆盖路径选型、迁移前的评估项、分区副本重分配的完整步骤、数据校验与流量切换以及迁移过程中最容易翻车的几个坑。不管是裸机换机房、容器化改造还是云上云下互迁核心思路都能复用。1. 为什么挪Kafka集群比想象中更麻烦很多中间件迁移比如MySQL做到主从同步、切换IP就能解决大半问题。Kafka不一样它是一个“分区-副本”体系数据分散在多台Broker上同一份数据存在多个副本生产者和消费者直接连集群的任意Broker这导致迁移时要同时处理三件事数据本身要搬、副本关系要重建、客户端连接要平滑切换。另外还有一个容易被忽略的点Kafka集群往往承载着大量业务Topic这些Topic背后是不同的团队、不同的重要等级、不同的流量特征。有的Topic每秒写入几十MB有的Topic一天都没几条消息。迁移时如果一刀切地按统一节奏搬低峰期流量小的Topic很顺利高流量Topic则可能因为副本同步跟不上而产生一直迁不完的现象。Kafka迁移失败的后果也比一般服务严重。消息本身就是硬数据丢了很难找回消费端Lag被拉到几千万业务感知到的可能就是“数据延迟一天”更麻烦的是有些消费组在迁移过程中会频繁Rebalance导致消费者反复加入退出延迟和错误消息双双上升。所以迁移这件事第一原则永远是可以先慢但不能出错。我见过不少团队把Kafka迁移纯当成“重启服务加拷贝文件”最后要么是副本数低于预期要么是消费位移错乱要么迁移结束后才发现某个内部Topic还有副本挂在旧Broker上一撤机器就丢数据。这不是工具不行是迁移前没把盘点做透迁移中没把步骤拆细。2. 动手前先回答四个问题迁移路线怎么选2.1 四种常见迁移路径的对比Kafka迁移并没有一个万能方案。根据迁移范围和数据流的关系我把它分成四种实际操作时往往选择其中一种或组合使用。路径一分区副本重分配集群内换机器这是最常用、最平滑的方案适合“旧集群整体换成新机器”或“新增Broker然后下线旧Broker”。它的思路是新Broker先空节点加入现有集群通过 kafka-reassign-partitions 把每个分区的一部分副本搬到新Broker上等数据同步完成后新Broker逐步接管Leader角色最后旧Broker逐个下线。优点是不需要动生产者和消费者的代码数据还在同一个集群内不需要双写不需要外部同步工具。缺点是整个迁移过程依赖集群自身的副本复制对网络带宽、磁盘IO有消耗而且改造范围局限在“同一集群”内。路径二MirrorMaker 2 做跨集群同步适合跨机房容灾、云上云下迁移、大版本跨度升级比如2.x迁到3.x甚至4.x这类场景。MirrorMaker 2 会把源集群的Topic数据、消费组状态、Topic配置同步到目标集群迁移结束后客户端整体切换到新集群。优点是源集群和目标集群完全隔离风险面小缺点是数据是“异步同步”的存在秒级到分钟级的延迟迁移窗口内如果源集群写入了数据目标集群可能还没有完全追上切流时需要控制写入或接受短时丢新数据的可能性通常业务上可以接受一小段停写。路径三双写双读Parallel Consumption生产端同时写两级集群消费端优先读新集群并校验稳定后再摘掉旧集群。这种方式最安全但改造成本最大适合对数据完整性要求极高、且完全无法容忍停机窗口的金融类业务。Kafka迁移很少需要做到这一步因为上面的路径一已经能在保持客户端不变的前提下完成集群替换。路径四冷备迁移停写拷贝小集群、低要求场景先把消息停掉然后直接拷贝磁盘文件到新集群。这个只适合Topic极少、数据量极小、能接受长时间停写的内部实验环境生产环境请直接忽略。三种主路径横向对比我整理如下迁移路径适用场景停机窗口数据风险客户端改造成本复杂度分区副本重分配换机器、换机房、小版本升级几乎为零低无中MirrorMaker 2跨集群、跨机房、大版本升级分钟级可控中异步同步需切换连接信息中高双写双读金融级、零容忍丢数据零极低高高2.2 数据体量和带宽测算迁移前第一件事不是敲命令是搞清楚“集群里到底有多少数据、每天新增多少”。这一步决定了整体时间预期。我当时的测算方法很直接# 查看所有Topic的磁盘占用 du -sh /data/kafka/kafka-logs-* | sort -rh | head -20 # 查看所有Topic的分区总数 kafka-topics.sh --bootstrap-server localhost:9092 --list | wc -l有了总量之后把单位换算成GB再除以期望的同步带宽就能大致得到副本搬完需要的时间假设总数据量1.2TB三个副本全量重分配相当于要复制约2.4TB的数据原有副本保留新增副本复制一份。限流值设为50MB/s基础时间为 2400GB ÷ 50MB/s ≈ 13.7小时。但这不是精确值。实际操作中副本复制和线上实时写入是并行的新拷贝的数据会不断被业务写入覆盖需要反复追赶。我的经验是把理论时间再乘以1.5基本是迁移的合理预期。如果等不了这个时间就把限流调大但这时候要接受业务高峰期带宽被打满的风险。2.3 版本与客户端兼容性这是很多人忽略但在迁移时一定会遇到的坑。Kafka从2.x到3.x经历了很大的协议变化比如2.8版本之后可以完全脱离ZooKeeper、3.x正式引入KRaft模式。如果旧集群是ZooKeeper架构新集群想直接上KRaft客户端兼容性就得格外注意。我处理的方式是先查一次所有客户端的kafka-clients依赖版本确认最低版本不低于服务端支持的最低协议版本。凡是低于2.0的客户端建议先升级依赖再动集群否则迁移完连接不上新集群才是真正的灾难。2.4 迁移预案清单把评估项浓缩成一页纸迁移前逐项打钩[ ] 当前Kafka版本、Topic总数、分区总数、副本因子[ ] 磁盘总占用、单Topic最大占用、每日新增数据量[ ] 高峰写入QPS、消息平均大小、峰值带宽占用[ ] 消费组清单、各组Lag基线值、组长和联系方式[ ] 客户端版本分布、生产者和消费者连接方式域名/IP[ ] 监控面板是否覆盖Broker网络吞吐、磁盘IO、GC耗时、ISR伸缩[ ] 回滚方案旧集群保留时间、DNS切换记录、磁盘不格式化[ ] 迁移时间窗口选业务低峰期且预留至少1.5倍预期时间这张清单看似基础但80%的迁移事故都是因为其中一两项没提前确认比如“原来有个Topic的保留时间被改成7天”“有个消费组根本没人维护但还在跑”。迁移前把这些挖出来后面能省很多事。3. 分区副本重分配同集群内“乾坤大挪移”的完整实操如果你的场景和我一样是“集群整体换机器”或“扩容后缩容旧机器”那我强烈推荐分区副本重分配这条路。这个方案的底层逻辑一句话就能说清让新Broker以空身份加入集群然后靠Kafka自身的副本机制把数据逐步复制到新Broker上等副本同步完成后Ledger自然转移到新机器旧Broker就可以功成身退。3.1 为什么优先选它而不是MirrorMakerMirrorMaker虽然看起来“更正规”但实际操作中要处理两套集群的Topic配置同步、消费组状态同步、客户端切换整个链路长得多。分区副本重分配的本质是“还是在同一个集群里数据没有出借只是换了个物理位置”所以生产者和消费者的连接信息不需要变还是连那一套bootstrap地址不需要保证“源集群-目标集群”的实时一致性问题因为根本不存在第二个集群迁移过程天然支持回滚只要旧Broker不关机下线随时可以把分区迁回去。当然它也有边界如果目标和源是完全独立的两个集群比如跨云厂商那重分配就无从谈起必须回到MirrorMaker。在“换机器不换集群”的场景里它就是最平滑的方案。3.2 新Broker加入集群前的准备工作新Broker对集群来说就是一台“新工人”。加入之前要保证几件事新机器的硬件规格不低于旧机器磁盘建议用吞吐更稳的SSD或NVMe盘server.properties中 broker.id 不得和现有Broker冲突建议从1001开始编号和旧Broker的0、1、2…区分开这样迁移后看分区分布一眼就能知道哪些副本已经搬过去了配置的log.dirs路径、zookeeper.connect或controller.quorum必须和旧集群一致先只启动一台新Broker观察它能否顺利注册成功、是否有分区被自动均衡过去默认配置不会自动迁移所以通常只是加入集群待命。我习惯的做法是一次只加入一台新Broker确认稳定后再加第二台。一次加太多控制器Controller的Leader选举压力会突然上升在高峰期可能引发短暂不可用。3.3 生成分区重分配计划假设现在集群有 0、1、2 三台旧Broker新Broker为 1001、1002、1003。先让三台新Broker全部加入集群且状态正常然后生成一份“把全部分区均匀摊到6台Broker”的计划# 生成迁移JSON重点看v2版本支持 --bootstrap-server kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --generate \ --broker-list 0,1,2,1001,1002,1003 \ --topics-to-move-json-file topics.json \ reassignment.json这里需要一个 topics.json格式长这样{ version: 1, topics: [ {topic: order_events}, {topic: user_action_log} ] }注意这一步生成的是全量重新均匀分配的方案它会把所有Topic的副本从“只在旧三台”改为“分布在六台”。如果你希望控制某些核心Topic不要全部摊开可以手工编辑生成的 reassignment.json把相关分区的 replica 数组只指向指定的三台新Broker。我实际操作时对几个高流量Topic做了手工锁定不为别的就是为了让它们的副本能优先在新机器上集合便于后续单独验证。3.4 分批执行并带上限流生成计划后不要一股脑全量执行。Kafka官方提供的方案是每次最多处理同时移动的分区数大约100到200个分区比较合适。分区数太多的话控制器要一次性给大量副本下发移动指令轻则IO打满重则控制器线程阻塞导致Leader选举延迟。执行时我建议带上限流参数# --throttle 单位是字节/秒这里设置为 50MB/s kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --execute \ --reassignment-json-file reassignment.json \ --throttle 52428800限流参数的作用是限制副本复制的峰值带宽防止迁移把机房带宽吃满导致业务流量抖动。它不影响正常的消息读写吞吐因为正常业务流量走的是磁盘写入路径副本复制是后台任务限流只针对副本复制部分。关于限流值怎么定我自己的估算方式是先看日常Broker峰值带宽比如单Broker峰值占用200MB/s那么全集群限流设在50MB/s留足余量。如果是内网千兆环境限流不建议超过80MB/s万兆环境可以放宽到200MB/s但还是要结合实际负载做微调。3.5 验证与重复执行每执行完一批等它收敛后必须验证kafka-reassign-partitions.sh \ --bootstrap-server localhost:9092 \ --verify \ --reassignment-json-file reassignment.json看到所有分区状态变为Reassignment completed才表示这一批搬完了。如果出现Reassignment in progress先别急着执行下一批查一下是哪个分区在拖后腿多数是Topic写入量太大副本一直在追赶业务写入。一批验证完后重复 3.3 到 3.5 直到所有分区都迁到目标Broker上。3.6 千万别跳过内部Topic的重分配这是我第一次做迁移时踩过的坑。重分配计划如果只覆盖了业务Topic那么 __consumer_offsets 这个存放消费位移的内部Topic它的副本还是全部留在旧Broker上。当你下线旧Broker时这个内部Topic的副本数直接跌破1消费者组会集体失联消费位移也会出现读取异常。处理方式很简单在生成迁移计划时把内部Topic也纳入范围。Kafka不允许你直接用kafka-topics.sh --list看到它但reassign的--topics-to-move-json-file里可以把它写进去。例如{ version: 1, topics: [ {topic: order_events}, {topic: __consumer_offsets} ] }操作完之后再把 __consumer_offsets 的分布打出来确认一遍kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic __consumer_offsets正常情况下它的每个分区副本应该均匀落在所有旧Broker和新Broker上。4. 数据校验、流量切换与回滚的细节方式分区副本重分配完成之后直观上数据已经“到”新Broker了但还不能直接下线旧Broker。我在这一步做的校验和切换基本可以分成四个动作。4.1 分区日志大小与Lag双维度校验第一个维度是看分区Leader是否已经转移到新Broker上。因为分区迁过去后Leader不一定立刻切到新的副本上需要主动触发或者等待旧Leader因为某些原因失联。Kafka有一个机制叫优先副本选举我们可以用它把Leader切到新Broker# 对所有已分配的Topic执行优先副本选举 kafka-leader-election.sh \ --bootstrap-server localhost:9092 \ --topic order_events \ --partition 0 \ --election-type preferred第二个维度是看数据是否完整。最直接的做法是对比新旧Broker上分区目录的大小但不是所有分区都能做到字节级一致因为那边可能还留着一些被清理完的历史文件。更可靠的依据是消费组Lagkafka-consumer-groups.sh \ --bootstrap-server localhost:9092 \ --describe --all-groups如果所有消费组的LAG列均为0或迁移前的基线水平说明消息从生产端到消费端整条链路是通的。如果还有消费组Lag异常偏高先排查是数据没搬到还是消费端本来就没跟上不能带着大Lag下线旧集群。4.2 客户端的三种切换方式分区副本重分配的场景下客户端连接方式基本不用大动但新旧Broker节点列表需要平滑切换。实际操作中我见过三种方式方式一DNS域名切换最推荐客户端配置里不写具体Broker IP而是写一个域名比如 kafka.internal.example.com通过DNS解析到各Broker。迁移前把它解析到旧Broker迁移完成后把解析记录切到新Broker客户端重启后自动连接新节点。这种方式回滚也快把DNS记录切回去就行。方式二改bootstrap.servers后滚动重启在代码或配置中心修改bootstrap.servers列表逐个滚动重启生产者和消费者。这种方式需要业务方配合但可以做到客户端无感因为Kafka客户端天然支持Broker列表变化。缺点是如果客户端数量庞大滚动重启耗时很长。方式三独立的连接网关/代理层对客户端隐藏真实Broker地址统一指向一个代理层由代理转发到实际集群。这个方案适合客户端特别多、不方便逐个改配置的团队但因为每个消息都要多一跳延迟会增加还需要单独维护代理高可用除非团队有余力否则不太推荐。4.3 旧Broker下线流程旧Broker的下线一定要稳健我习惯分三步先确认所有业务Topic和内部Topic的副本都已经迁移出旧Broker通过kafka-topics.sh --describe检查任何分区的副本都不再包含待下线Broker的ID用kafka-server-stop.sh或 systemctl 停止旧Broker进程观察集群是否出现异常告警等5到10分钟观察Controller有没有反复选举、ISR有没有收缩、生产端有没有报错确认稳定后再停下一台。一次只停一台不要同时停多台。旧Broker停掉后它的数据盘先保持原样一段时间不要立刻格式化或用于其他用途我通常保留至少3个自然日最多一周。4.4 回滚预案的两种触发条件迁移过程中的回滚与普通发布回滚本质一致只有在新状态出现问题时才回切旧状态。分两种情况迁移过程中出现问题比如某批分区迟迟无法收敛直接取消未完成的迁移任务已经搬过去的分区可以后续再搬回来旧Broker没有下线所以集群本身仍然健康问题不大迁移完成后、新旧切换出现异常比如新Broker频繁GC、消费Lag暴涨通过DNS切回旧Broker列表客户端重启后重新连回旧集群。第二种情况记得先别急着把旧Broker的进程停干净留一台作为回滚入口整体回滚动作控制在10到20分钟内可以完成。5. 迁移中的真实坑位延迟飙升、副本失配与Rebalance风暴5.1 迁移期间消息延迟为什么突然变高这是几乎每次Kafka迁移都会遇到的症状。消息延迟高的表象是消费者看到的Lag在增长生产端感知的写入超时也在增加。其根本原因是副本复制占用大量网络和磁盘IO导致消息落盘和副本确认变慢。我当时观察到一个很典型的现象迁移限流从50MB/s调到80MB/s后整个集群的网络吞吐确实上来了但生产端的producer队列时间从原来的2毫秒涨到了200毫秒。原因是消息确认机制acksall要求所有ISR副本都写入成功而副本复制本身的优先级并不高于正常业务写入在带宽饱和的情况下正常消息写入只能排队等待。解决这个问题的思路不是放弃限流而是把迁移窗口和业务高峰错开同时在限流参数设置上“宁慢勿快”。还有一个细节值得提迁移期间可以把生产端的acks暂时从all降为1减少单个消息等待副本确认的时间但这会带来短时数据丢失风险非必要不要动。5.2 分区副本一直“搬不完”的排查链路有一次我遇到一个Topic迁移计划执行后两小时还挂在in progress状态一直不变。踩过的经验告诉我这时候不能干等按下面的链路排查看副本是否在持续增量同步kafka-reassign-partitions.sh --verify如果一直在跑大概率是数据在追赶实时写入看具体分区的Leader在哪如果Leader还在旧Broker上同步过程会额外消耗一次转发必要时手动触发Preferred Leader Election看限流是否设得太低50MB/s对一个单Topic每秒写入80MB的业务来说永远跑不赢要么提高限流值要么先暂停该Topic的生产流量如果业务允许看网络是不是被其他任务占满当时检查时发现集群同时有另一个数据同步任务加起来已经把带宽打满这才找到根本原因。排查下来最有效的手段其实就是先降低该Topic的写入压力再调高限流让副本复制追上实时数据然后分批完成搬迁。5.3 消费组在迁移过程中频繁Rebalance怎么办分区副本重分配过程中Broker的下线动作会触发分区Leader切换消费者会因为连接断开而触发组内Rebalance。Rebalance本身是正常机制但如果频繁发生会导致消费者成员反复加入退出消费停顿和重复消费并行出现。我碰到的Rebalance风暴大多是session.timeout和heartbeat.interval参数设置太短导致的。在迁移窗口内把消费者的session.timeout.ms从默认的45000调到90000heartbeat.interval.ms从3000调到10000能明显降低这类“假失联”的触发概率。这个改动不需要改代码在启动参数或配置中心临时调整即可迁移完成后改回默认值。5.4 迁移中如何直观判断进度UI工具和监控日常管理Kafka迁移用命令行工具确认状态是基本功但想一目了然地看到副本分布、Leader分布、分区流量建议部署个Web UI。我用过几款简单对比工具项目状态迁移相关的强项不足Kafka UI原kafka-ui活跃分区副本分布直观、支持查看Reassign状态不看限流细节EFAK原Kafka Eagle偏运维向监控项丰富、Lag告警完整界面稍老旧Kafka Manager维护少能看副本和Leader分布新版本适配一般迁移过程中我主要靠Kafka UI看副本是否均匀摊到新Broker上以及每台Broker的流量是否有明显倾斜。眼见为实命令行再准确也代替不了可视化面板对整体局面的判断。5.5 一个小技巧迁移完成后用“平衡状态”验收迁移完成不等于所有分区都均匀分布。Kafka的副本分布在你手动搬迁的过程中往往会留下“有些不均匀”的尾巴比如某些Broker上副本数偏多另一些偏少。条件允许的话迁移完成后再执行一次kafka-reassign-partitions.sh --generate把--broker-list换成只包含新Broker生成一份纯新集群的均衡方案让副本分布回归健康。这一步做完之后集群的运行状态才算真正进入“平稳期”。我在那次迁移后观察了一周消息延迟恢复、消费组Lag稳定、Controller无异常切换整体才敢说迁移成功。回看整个过程Kafka迁移最耗费心力的地方从来不是敲那几条命令而是前期的数据摸底、路径选择、限流节奏和回滚预案。只要这些想清楚了实际操作就是一步步推进的事。