最近好几个朋友都不约而同地问我同一个问题Kafka迁移到底应该怎么做有人要把自建集群搬到云上有人要把旧版本集群升级到新架构还有人只是想换掉一批老节点结果发现网上那些操作手册和自己遇到的场景完全对不上。说实话Kafka迁移这个题目看着简单真做起来坑非常多。它不是一个“把数据从A拷贝到B”的问题而是一个需要同时考虑数据一致性、消费者位点、Topic配置兼容、参数对齐、切换窗口、回滚预案的系统工程。这篇文章我就把做过几次迁移的经验完整梳理一遍从场景判断、方案选型到实际操作、问题排查都覆盖到适合正在搞集群搬迁、Kafka升级、节点替换的运维和开发同学。1. 迁移前先想清楚你是哪种迁移要解决什么问题1.1 三种典型迁移场景集群搬迁、节点扩容/缩容、跨版本升级Kafka迁移的第一步不是敲命令而是先给这次迁移定性。我见过太多人上来就搜“MirrorMaker怎么配置”结果他的场景根本不需要跨集群复制白白搭进去一个组件还有一堆运维负担。按我的经验日常遇到的迁移基本可以归成三类。第一类是整体集群搬迁。典型场景是机房退租、上云、自建转云托管整个集群要换到新环境。这种情况下Topic、消费者组、存量数据全部要移动而且往往有停机窗口限制业务不能断太久。这类迁移最复杂也是本文主要展开的场景。第二类是集群内节点替换。比如某几台broker要退役、磁盘报警要换盘、或者单纯想扩容横向加节点。这时候集群本身不换只是把分区从旧节点挪到新节点。很多人不知道的是这类场景根本不需要跨集群复制用Kafka自带的kafka-reassign-partitions.sh就能在线完成。第三类是跨大版本升级。比如从0.10直接升到3.x除了搬数据还要考虑协议兼容、消息格式差异、客户端版本是否匹配。这类迁移涉及的东西比较杂经常需要结合双写或MirrorMaker来做灰度推进。这三种场景的解决思路完全不同。如果你不先判断类型很容易选错方案。我一般会先问三个问题集群要不要整体换业务允不允许停机客户端代码能不能改答案一旦清楚方案基本就浮出水面了。1.2 先盘点存量Topic、分区、副本、消息量、保留策略Kafka迁移最忌讳的就是“对着一个Topic就开始搬”。动手之前必须盘家底而且是要盘得非常细。否则你连要准备多少磁盘、复制链路要多宽、数据校验要跑多久都说不出来。需要盘的东西包括这几类所有Topic的列表和配置直接用bin/kafka-topics.sh --bootstrap-server old:9092 --list和--describe就能拿到。注意看每个Topic的分区数、副本因子、retention.ms、cleanup.policy。然后是每个Topic的流量特征峰值写入速度、单条消息大小、每秒消息数。这个数据最好从broker的JMX监控里拉如果之前没监控就得趁迁移前补上否则后面做容量规划就是拍脑袋。消费组也要拉一份清单bin/kafka-consumer-groups.sh --bootstrap-server old:9092 --describe --all-groups确认有哪些group、分别消费哪些Topic、当前Lag是多少。最后是broker资源情况磁盘使用率、IO util、网卡带宽这些决定了你新集群的硬件选型。我通常会做一个容量计算示例比如某个订单Topic峰值写入2MB/s单条消息平均4KB保留7天副本因子2。单日数据量是2MB/s乘以86400秒约172.8GB7天就是1.2TB再乘以副本2得到2.4TB最后留出30%缓冲约3.1TB。这个数字才是你给新集群配磁盘的依据。这里想强调一个经验Kafka迁移里总数据量其实不是主导因素真正决定迁移难度的是峰值写入速度和保留时长。这就像搬家你真正要关心的是每天产生多少新东西、垃圾桶多久清一次而不是数家里一共有多少件旧家具。1.3 迁移目标选型版本、集群规模、磁盘与网络规划存量盘清楚后就是给新集群做选型。版本方面现在新项目基本都选3.x以上并且建议直接用KRaft模式也就是不依赖Zookeeper的那种部署方式运维负担明显小很多。如果团队对KRaft还不太信任3.x也支持传统ZK模式可以平滑过渡。关键不是追求最新而是选一个你们团队真正能运维得起来的版本。集群规模要根据分区总数和峰值吞吐来估算。我的经验值是单broker分区数控制在2000以内比较稳超过5000就会有明显的性能风险。副本因子生产环境至少2推荐3。磁盘方面Kafka是顺序写盘机械硬盘也能扛一定吞吐但延迟敏感的业务还是优先SSD尤其是要做消息检索或重放的场景SSD提升非常明显。网卡至少千兆起步跨机房对等连接建议专线或万兆否则同步延迟会很难看。新集群的Topic规划有个原则迁移阶段尽量和旧集群保持一致分区数、副本数、retention这些先照搬让客户端和业务逻辑零改动。等迁移完成、系统稳定运行一段时间后再根据实际流量做分区调整或参数调优。一上来就“顺手优化”分区设计往往会引入额外变量出问题了很难定位是新环境的问题还是改造的问题。2. 迁移方案对比双写、MirrorMaker 2、还是分区重分配2.1 应用侧双写最土但最可控应用侧双写是最“不优雅”但最可控的迁移方式。思路很简单改造生产者的发送逻辑让每条消息同时写入新旧两个集群。业务通过配置中心控制写入开关按Topic或者按实例灰度切换整个过程完全由你自己掌控节奏。双写的优点很明显无需额外组件不需要部署MirrorMaker数据同步的时效性完全取决于业务发送链路理论上比任何异步复制都快。另外切换非常灵活今天可以只让10%的消息打到新集群观察稳定后再加大比例。但缺点也必须提前想清楚。第一业务代码一定要改如果系统里几十个服务都在直连Kafka改造成本会很高。第二消息重复不可避免。两条链路都可能出现部分成功的情况比如新集群写失败但旧集群写成功了下游消费时如果不做幂等必然会有重复消息。第三双倍流量会对生产链路和下游造成额外压力一些对延迟敏感的核心链路需要评估是否承受得住。实际操作时我习惯在Producer外面包一层路由底层还是原生的KafkaProducer只是发送前根据路由规则复制一份到另一个Producer实例。这里有个很容易踩的坑两个集群都写失败时怎么办降级策略一定要提前定好。我的经验是新集群写失败只记录日志和指标不影响主链路旧集群写失败则直接抛异常触发原有告警因为那才是当前真正在用的链路。双写方案适合业务可改造、迁移时间充裕、希望全程能灰度控制的团队。它不适合那种几十个老系统都直连Kafka、代码已经没人敢动的场景那种场景还是老老实实用MirrorMaker。2.2 MirrorMaker 2跨集群复制的官方方案如果你不想改业务代码那MirrorMaker 2简称MM2基本是首选。它是Kafka官方自带的跨集群复制工具从2.4版本开始就是标准答案。它的本质是一个跑在Kafka Connect框架上的应用用内置的Source Connector消费源集群的Topic再通过内置Producer把数据写入目标集群。MM2比老版MirrorMaker强的地方在于它不只是复制数据还会同步消费组offset、Topic配置、ACL等元数据。特别是checkpoint机制它会定期把源集群消费组的位点记录到目标集群的专用Topic里。这个能力对迁移来说非常关键它决定了你切换消费者后能不能从旧集群的断点继续消费而不是从头消费或者从末尾消费。用MM2做迁移的最大优势就是业务零改造不用碰任何Producer和Consumer代码只要部署一个MM2进程就能把整条数据管道搭起来。同时它支持双向复制也符合容灾演练的场景。缺点方面MM2是异步复制目标集群数据始终存在一定延迟几秒到几十秒都有可能具体取决于网络和负载。此外复制过程中也可能产生重复消息下游消费最好有幂等兜底。如果只是迁移需求我通常只开单向往目标集群复制不开反向。双向复制在容灾场景才有意义迁移阶段开双向容易造成消息循环给自己增加不必要的复杂度。2.3 分区重分配集群内节点迁移的正确打开方式这里单独说一下集群内节点替换的场景。很多人一听到迁移就想到跨集群复制其实如果只是要换掉某几个broker用Kafka原生的分区重分配工具就够了完全不需要MirrorMaker。原理上kafka-reassign-partitions.sh会把指定分区的数据在broker之间做增量复制等新副本追平到leader之后切换leader再删除旧副本。整个过程是在线完成的不需要停机但会在迁移期间产生额外的磁盘和网络IO。所以我的建议是尽量在业务低峰期执行并且用--throttle参数限速比如限到50MB/s避免把集群IO打满。操作流程一般是三步。第一步用kafka-reassign-partitions.sh --generate生成候选迁移方案它会根据当前分配情况输出一个JSON分配方案第二步把方案改到只包含你想迁移的Topic和分区然后用--execute执行第三步用--verify观察迁移状态直到所有分区都显示completed。这里有个重要经验重分配一个批次不要挪太多分区一批一批来。你一次把所有分区都搬过去中间某个节点挂了整个集群的稳定性都会受影响。我习惯一次最多挪几十个分区跑完一批确认稳定再做下一批。整个过程虽然慢但稳。2.4 如何选停机窗口、一致性、改造成本方案选型的核心就三个变量停机窗口、数据一致性要求、业务改造成本。我整理了一个简单的对比表方案停机时间业务侵入数据一致性复杂度适用场景冷拷贝停写需要无高低允许停机的小集群应用双写不需要高中可能重复中业务可改造、可灰度MirrorMaker 2不需要低中异步中高整体跨集群迁移分区重分配不需要无高低集群内节点替换如果停机窗口比较富裕其实可以选最土的冷拷贝方案停掉所有生产写入把Kafka数据目录或者用工具搬迁存量数据然后在新集群启动消费。这个方案数据一致性最高操作也最简单问题就在于业务要能接受停机时间哪怕只有十几分钟也不是所有系统都扛得住。生产环境多数不能接受长时间停机所以“MirrorMaker 2/双写 消费组offset同步”是主流组合。面试时如果被问到Kafka怎么做迁移先问清楚能不能停机、要不要改代码、是跨集群还是集群内换节点然后再给方案基本就能加分。高手不是会敲一条命令而是会做方案取舍。3. 实操用 MirrorMaker 2 做一次跨集群迁移3.1 环境准备本地 Windows 快速搭一套测试集群很多同学本地是Windows想先搭一套环境验证方案。Kafka官方其实没有提供Windows安装包但二进制包解压后是可以直接跑的只要把JDK配好。Kafka 3.x以上推荐用KRaft模式不用装Zookeeper比很多老教程舒服得多。步骤不复杂。先下载Kafka二进制包比如kafka_2.13-3.6.2解压到C:\kafka。然后把JAVA_HOME指向JDK 11或17PATH里加好bin目录。接着编辑config\kraft\server.properties关键配置改成这样process.rolesbroker,controller node.id1 listenersPLAINTEXT://localhost:9092,CONTROLLER://localhost:9093 advertised.listenersPLAINTEXT://localhost:9092 controller.quorum.voters1localhost:9093然后打开命令行先执行bin\windows\kafka-storage.bat random-uuid生成一个集群ID保存下来。再执行bin\windows\kafka-storage.bat format -t uuid -c config\kraft\server.properties格式化存储目录最后用bin\windows\kafka-server-start.bat config\kraft\server.properties就能把单节点Kafka跑起来。想模拟新旧两个集群就再复制一份目录把server.properties里的node.id改成2端口改成9192和9193再格式化启动一次。两个本地集群就能跑通后面的MM2流程。Windows下有几个常见坑路径带中文会报错JDK版本太老起不来改了listeners但忘了改advertised.listeners会连接失败。这些细节排查起来很耗时间。这里的重点是搭一个能复现迁移流程的测试环境不是为了性能验证。生产环境还是建议Linux裸机或容器化部署Windows当个验证工具足够了。3.2 MirrorMaker 2 的配置与启动步骤本地假设有两个集群source监听localhost:9092target监听localhost:9192。我们需要把source的Topic复制到target。新建一个mm2.properties配置文件核心内容如下clusters source, target source.bootstrap.servers localhost:9092 target.bootstrap.servers localhost:9192 # 单向复制source - target source-target.enabled true source-target.topics .* target-source.enabled false # 自动创建目标集群Topic source-target.topic.auto.create true # 同步消费组offset source-target.emit.checkpoints.enabled true source-target.sync.group.offsets.enabled true启动命令是bin/kafka-mirror-maker2.sh config/mm2.propertiesWindows下就是bin\windows\kafka-mirror-maker2.bat。启动后到target集群里看会发现多了一批新Topic名字默认带source.前缀比如source.orders。这个前缀是MM2故意设计的目的是防止双向复制时消息循环。但对迁移场景来说我们通常希望目标集群的Topic名和源集群完全一致这样客户端切换配置时最省事。要实现这一点需要自定义一个ReplicationPolicy。写一个Java类继承DefaultReplicationPolicy重写formatRemoteTopic方法import org.apache.kafka.connect.mirror.DefaultReplicationPolicy; public class NoPrefixReplicationPolicy extends DefaultReplicationPolicy { Override public String formatRemoteTopic(String topic) { return topic; } }编译成jar放到Kafka安装目录的libs下然后在mm2.properties里指定replication.policy.classNoPrefixReplicationPolicy。这样复制出来的Topic名就和源集群一致了。这里必须提醒一句一旦用了无前缀策略千万别再开双向复制否则两个集群互相复制消息会无穷循环。单向复制不受影响。另外Topic比较多时建议先用正则限定范围比如source-target.topics orders\|payment\|user_events验证没问题后再放开全量避免一开始就复制一些不需要的Topic。3.3 验证数据完整性消息数、位点、时间戳复制跑起来之后最容易被忽视的就是验证环节。我见过有人启动MM2后看到两边Topic都存在就宣布迁移成功结果过几天业务方发现有消息对不上因为某些分区offset没追上。第一层验证是对比各分区offset。在source集群执行bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic orders --time -1target集群也执行相同命令然后把每个分区的log end offset逐行对比。更稳一点的做法是写个脚本先拿每个分区的log start offset再拿log end offset两者之差就是该分区的消息总量然后两端对比。注意不要只看总和分区粒度上的对比才能暴露具体是哪个分区出了问题。第二层验证是抽样比对消息内容。用console consumer把部分分区的消息导出或者写一个简单的Kafka Consumer对每条消息的key和value做哈希放到一个Map里再对另一端做同样操作比对是否有差异。抽样不需要全量但每个分区都要覆盖到。这一步能发现offset对得上但内容不对的场景比如序列化问题或者复制链路中间处理逻辑有问题。第三层验证是消费端位点。在source集群查看业务消费组的当前位点bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-consumer-group如果MM2的checkpoint同步开启target集群会有一个同名group.id的消费组位点应该接近source。这个值决定了切换消费者后能不能从旧集群断点继续消费。实操心得MM2是异步复制目标集群总会比源集群慢几百毫秒甚至几秒这是正常现象。验收标准不要写成“两边完全一致”而是定义“差距在可接受范围内且不持续增大”比如5秒以内就算通过。3.4 流量切换与客户端割接数据校验通过后进入切换环节。这里的顺序非常重要我强烈建议先切消费者后切生产者。为什么不能先切生产者因为如果先把生产者切到新集群旧集群的消费者还在旧集群消费新写入目标集群的消息旧消费者完全看不到业务直接就断了。反过来先切消费者因为MM2持续把源集群新消息同步到目标集群消费者切过去后虽然可能短暂滞后但很快会追平。具体操作分四步。第一步确认target集群已有同名消费组并且offset与source集群接近这样才能续接消费位点。第二步把消费者客户端的bootstrap.servers从旧地址改到新地址分批灰度切换改完后立刻观察新集群这个消费组的lag确认是从同步的位点继续消费而不是从头或从尾部开始。第三步消费者全部切完并稳定后再切生产者同样分批灰度。第四步全部切完后MM2可以继续运行一段时间作为备份链路但要注意复制方向不能开反向否则会产生循环复制。这里有个很常见的坑消费者切过去后发现位点不对从开头开始消费了。原因一般是sync.group.offsets.enabled没开或者源目标和客户端里的group.id不一致或者目标集群这个group之前被手动消费过导致checkpoint失效。检查这三个点基本能定位。切换过程中如果用了自定义ReplicationPolicy去掉了Topic前缀还要注意一点客户端不能同时连接两个集群去订阅同一个名字的Topic元数据会互相覆盖导致路由混乱。所以切换期间最好是同一进程内只指向一个集群不要新旧集群地址同时挂在同一个客户端配置里。4. 迁移中的兼容性与坑大消息、延迟、版本差异4.1 单条 1MB 大消息的配置与验证搜索Kafka相关问题时经常能看到类似“kafka 接收1m”的关键词这说的就是Kafka默认单条消息大小上限是1MB。很多业务在迁移阶段才暴露出这个问题旧集群可能早就被运维调大了参数新集群还是默认值一切过去立刻报RecordTooLargeException。需要对齐的参数有好几层我先列个表位置参数默认值调整方向brokermessage.max.bytes1048576调到目标单条上限如10485760brokerreplica.fetch.max.bytes1048576必须大于等于message.max.bytesbrokersocket.request.max.bytes104857600按需调大producermax.request.size1048576大于等于单条消息上限consumermax.partition.fetch.bytes1048576大于等于单条消息大小consumerfetch.max.bytes52428800按批量消费需求调整我经常看到有人只改了broker的message.max.bytes忘了改replica.fetch.max.bytes结果副本同步时一直报错副本长期处于UnderReplicated状态。这两个参数必须一起调整。验证方法很简单写一段Producer代码发送一条2MB的字节数组到目标集群能正常发送、能被消费参数才算配好Properties props new Properties(); props.put(bootstrap.servers, localhost:9192); props.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer); props.put(value.serializer, org.apache.kafka.common.serialization.ByteArraySerializer); props.put(max.request.size, 10485760); ProducerString, byte[] producer new KafkaProducer(props); byte[] bigPayload new byte[2 * 1024 * 1024]; producer.send(new ProducerRecord(orders, migration-key, bigPayload)).get(); producer.close();迁移前把新旧集群这套参数全部对齐并实际用大消息测一遍能节省非常多线上排障时间。图片、日志大字段、埋点大JSON在真实业务里非常常见不是极端场景。4.2 迁移后消息延迟变高的排查思路切到新集群后业务反馈“消息延迟高”是高频问题。出现这种情况不要急着怪新集群性能差先按环节拆解到底是生产者到broker慢还是broker到消费者慢。我排查时会先看broker的CPU、磁盘IO、GC。磁盘IO是很多迁移翻车的地方旧集群用了SSD新集群却配了普通HDD顺序写差距可以达到好几倍。然后是生产者侧指标batch size、linger.ms、compression.type、acks。acksall时如果副本数从2变成了3确认时间自然会变长linger.ms0时小消息每一条都单独发送网络往返成本非常高。消费者侧要关注max.poll.records、max.poll.interval.ms、session.timeout.ms。消费者处理不过来lag就会涨整体表现就是消息延迟高。还有一个特别隐蔽的坑跨机房网络。新旧集群不在同一个机房时客户端切换后的RTT会明显上升尤其是同步发送加acksall延迟直接翻倍。物理距离带来的延迟不是调参能完全消除的尽量让新旧集群在迁移窗口内处于同一网络区域或者至少用专线打通。我整理了一个快速排查表现象可能原因查找方式对策producer send耗时高linger.ms太小/batch太小producer metric batch-size调整batch.size和linger.ms考虑开启压缩消费lag持续涨消费者处理慢/分区不够kafka-consumer-groups --describe增加消费者实例或分区优化消费逻辑副本同步异常replica.fetch参数没对齐kafka-topics --describe 看ISR对齐大消息相关参数端到端延迟大网络RTT高/跨机房ping、专线路由监控迁移期间尽量同机房或调整生产者确认模型另外还有一个现象客户端改了bootstrap.servers指向新集群后可能还连着一部分旧broker。这是因为客户端会缓存元数据不会立刻丢弃旧的broker连接。出现这种情况时最直接的办法是重启消费者进程等metadata刷新后再观察。4.3 客户端版本兼容与序列化迁移前还要盘一下所有客户端的Kafka版本。Kafka服务端对老客户端有兼容性策略但也不是无底线地兼容。0.10.2以上的客户端连3.x基本没问题0.9或者更早的版本新集群默认可能会拒绝老协议。除了协议版本消息格式也是一个隐蔽问题。新集群默认消息格式是v2如果你的消费者仍然是老版本kafka-client并且没有做兼容设置可能出现反序列化或CRC校验问题。稳妥做法是迁移前把客户端统一升级到0.11以上如果确实无法升级可以在新集群设置log.message.format.version为旧版本对应的值但这个参数在新版本中有废弃趋势终归要升级客户端。序列化方面容易被忽略。Kafka本身不关心消息内容格式但迁移验证时如果你按JSON或AVRO去解析就必须确保新旧两边的schema一致。特别是用了Confluent Schema Registry的场景新集群客户端需要指向新的registry地址同时把schema同步过去否则消费者反序列化直接报错。我在实际迁移中一定会做一张“客户端清单”列清楚每个服务用的kafka-clients版本、序列化方式、是否使用Schema Registry、消费组ID是什么。别嫌这张表麻烦等出了问题再去翻代码成本翻十倍都不止。5. 迁移后的观测与运维UI界面、监控、性能对比5.1 Kafka UI 工具推荐顺带回答那个高频问题Kafka有没有UI界面答案是不仅有而且选择非常多。迁移验证阶段我肯定会装一个UI直观看到新旧两个集群的Topic、分区和消息情况比敲命令行舒服很多。常见选择工具类型特点适用场景Kafka UIWeb多集群、消息查看、consumer管理社区活跃日常运维首选Offset Explorer桌面客户端查看Topic、分区、offset非常方便本地快速调试KafdropWeb轻量看消息直观临时排查CMAK (Kafka Manager)Web老牌管理工具偏集群管理老版本集群迁移期Prometheus GrafanaWeb监控指标监控必备生产环境告警经验提醒生产环境的UI工具建议只做只读用途不要在UI里直接改Topic配置、删消费组。这些操作很容易误点尤其Kafka UI新版本交互改动频繁我见过同事点错按钮把消费组重置了的情况。要改配置还是用命令行加权限控制比较稳妥。5.2 监控指标与性能对比迁移完成后不是看一眼lag能消费就算完。正确姿势是建立一套核心指标监控把新旧集群迁移前后做个对比确认新集群确实承接住了原流量。重点盯这几个指标BytesIn/BytesOut表示集群吞吐确认有没有流量异常MessagesInPerSec是每秒消息数和业务预期对照RequestHandlerAvgIdlePercent是请求线程空闲率长期低于30%说明broker线程快被耗尽需要调大num.io.threadsNetworkProcessorAvgIdlePercent同理。UnderReplicatedPartitions是副本同步落后分区数长时间大于0说明某台broker写入慢或网络有问题OfflinePartitionsCount必须是0IsrShrinksPerSec和IsrExpandsPerSec如果频繁跳动说明broker性能波动大。用Kafka exporter配合Grafana模板就能搭一套不用自己从零画图。迁移后第一天要重点盯UnderReplicatedPartitions和IsrShrinksPerSec因为新集群的副本同步往往是最弱的环节。性能对比也可以用压测脚本验证。Kafka自带工具bin/kafka-producer-perf-test.sh --topic orders --num-records 1000000 --record-size 1024 --throughput 10000 --producer-props bootstrap.serverslocalhost:9192 linger.ms10 batch.size65536bin/kafka-consumer-perf-test.sh --bootstrap-server localhost:9192 --topic orders --messages 1000000 --reporting-interval 1000压测前先确认Topic分区数足够如果分区数太少吞吐会被单个分区上限卡死。压测结果不一定代表生产真实水平但用来做新旧集群的横向对比很有参考价值。5.3 迁移验收与回滚兜底验收维度我习惯列一个清单逐项打勾。新旧集群各项Topic配置要一致包括分区数、副本数、retention、cleanup.policy、min.insync.replicas。新旧集群各分区offset差值要低于设定阈值。业务消费组在新集群运行正常lag稳定在低位。核心链路场景要人工验证通过比如下单、支付回调、报表任务这些真实业务动作不能只看监控。监控告警全部切换到新集群旧集群告警可以保留但降噪。再说回滚。我的原则是旧集群不要急着下线。最稳的回滚策略是保留旧集群和复制链路至少一个完整保留周期假设retention设置的是7天就留满7天。如果切换后发现问题生产者切回旧集群消费者也切回旧集群位点还在业务能迅速恢复。新集群这段时间积累的数据可以手工补数尽量减少损失。回滚期间最忌讳的操作是删Topic、删消费组、清空offset。这些动作一旦做了旧集群就真的回不去了。所以下线旧集群前一定要让负责人确认数据已确认完好业务已稳定运行超过一个保留周期再动手清理。还有一个小细节迁移结束时MM2进程不要用kill -9粗暴停掉。如果你还在用默认复制策略它可能正在运行checkpoint同步直接杀掉容易留下未完成的内部状态Topic。正确做法是先把mm2.properties里的复制开关改成false或者停掉connect任务等内部状态Topic清理完再退出进程避免下次启动时出现offset错位。最后数据校验脚本千万别删留在团队里。每次迁移或者大版本升级都可能用得上。我自己的体会是Kafka迁移真的不是看谁命令敲得熟而是看谁能把停机窗口、数据校验、回滚预案这些“脏活”想在前面。把这套思路掌握住迁移过程再复杂心里也不会慌。
最近好几个朋友都不约而同地问我同一个问题Kafka迁移到底应该怎么做有人要把自建集群搬到云上有人要把旧版本集群升级到新架构还有人只是想换掉一批老节点结果发现网上那些操作手册和自己遇到的场景完全对不上。说实话Kafka迁移这个题目看着简单真做起来坑非常多。它不是一个“把数据从A拷贝到B”的问题而是一个需要同时考虑数据一致性、消费者位点、Topic配置兼容、参数对齐、切换窗口、回滚预案的系统工程。这篇文章我就把做过几次迁移的经验完整梳理一遍从场景判断、方案选型到实际操作、问题排查都覆盖到适合正在搞集群搬迁、Kafka升级、节点替换的运维和开发同学。1. 迁移前先想清楚你是哪种迁移要解决什么问题1.1 三种典型迁移场景集群搬迁、节点扩容/缩容、跨版本升级Kafka迁移的第一步不是敲命令而是先给这次迁移定性。我见过太多人上来就搜“MirrorMaker怎么配置”结果他的场景根本不需要跨集群复制白白搭进去一个组件还有一堆运维负担。按我的经验日常遇到的迁移基本可以归成三类。第一类是整体集群搬迁。典型场景是机房退租、上云、自建转云托管整个集群要换到新环境。这种情况下Topic、消费者组、存量数据全部要移动而且往往有停机窗口限制业务不能断太久。这类迁移最复杂也是本文主要展开的场景。第二类是集群内节点替换。比如某几台broker要退役、磁盘报警要换盘、或者单纯想扩容横向加节点。这时候集群本身不换只是把分区从旧节点挪到新节点。很多人不知道的是这类场景根本不需要跨集群复制用Kafka自带的kafka-reassign-partitions.sh就能在线完成。第三类是跨大版本升级。比如从0.10直接升到3.x除了搬数据还要考虑协议兼容、消息格式差异、客户端版本是否匹配。这类迁移涉及的东西比较杂经常需要结合双写或MirrorMaker来做灰度推进。这三种场景的解决思路完全不同。如果你不先判断类型很容易选错方案。我一般会先问三个问题集群要不要整体换业务允不允许停机客户端代码能不能改答案一旦清楚方案基本就浮出水面了。1.2 先盘点存量Topic、分区、副本、消息量、保留策略Kafka迁移最忌讳的就是“对着一个Topic就开始搬”。动手之前必须盘家底而且是要盘得非常细。否则你连要准备多少磁盘、复制链路要多宽、数据校验要跑多久都说不出来。需要盘的东西包括这几类所有Topic的列表和配置直接用bin/kafka-topics.sh --bootstrap-server old:9092 --list和--describe就能拿到。注意看每个Topic的分区数、副本因子、retention.ms、cleanup.policy。然后是每个Topic的流量特征峰值写入速度、单条消息大小、每秒消息数。这个数据最好从broker的JMX监控里拉如果之前没监控就得趁迁移前补上否则后面做容量规划就是拍脑袋。消费组也要拉一份清单bin/kafka-consumer-groups.sh --bootstrap-server old:9092 --describe --all-groups确认有哪些group、分别消费哪些Topic、当前Lag是多少。最后是broker资源情况磁盘使用率、IO util、网卡带宽这些决定了你新集群的硬件选型。我通常会做一个容量计算示例比如某个订单Topic峰值写入2MB/s单条消息平均4KB保留7天副本因子2。单日数据量是2MB/s乘以86400秒约172.8GB7天就是1.2TB再乘以副本2得到2.4TB最后留出30%缓冲约3.1TB。这个数字才是你给新集群配磁盘的依据。这里想强调一个经验Kafka迁移里总数据量其实不是主导因素真正决定迁移难度的是峰值写入速度和保留时长。这就像搬家你真正要关心的是每天产生多少新东西、垃圾桶多久清一次而不是数家里一共有多少件旧家具。1.3 迁移目标选型版本、集群规模、磁盘与网络规划存量盘清楚后就是给新集群做选型。版本方面现在新项目基本都选3.x以上并且建议直接用KRaft模式也就是不依赖Zookeeper的那种部署方式运维负担明显小很多。如果团队对KRaft还不太信任3.x也支持传统ZK模式可以平滑过渡。关键不是追求最新而是选一个你们团队真正能运维得起来的版本。集群规模要根据分区总数和峰值吞吐来估算。我的经验值是单broker分区数控制在2000以内比较稳超过5000就会有明显的性能风险。副本因子生产环境至少2推荐3。磁盘方面Kafka是顺序写盘机械硬盘也能扛一定吞吐但延迟敏感的业务还是优先SSD尤其是要做消息检索或重放的场景SSD提升非常明显。网卡至少千兆起步跨机房对等连接建议专线或万兆否则同步延迟会很难看。新集群的Topic规划有个原则迁移阶段尽量和旧集群保持一致分区数、副本数、retention这些先照搬让客户端和业务逻辑零改动。等迁移完成、系统稳定运行一段时间后再根据实际流量做分区调整或参数调优。一上来就“顺手优化”分区设计往往会引入额外变量出问题了很难定位是新环境的问题还是改造的问题。2. 迁移方案对比双写、MirrorMaker 2、还是分区重分配2.1 应用侧双写最土但最可控应用侧双写是最“不优雅”但最可控的迁移方式。思路很简单改造生产者的发送逻辑让每条消息同时写入新旧两个集群。业务通过配置中心控制写入开关按Topic或者按实例灰度切换整个过程完全由你自己掌控节奏。双写的优点很明显无需额外组件不需要部署MirrorMaker数据同步的时效性完全取决于业务发送链路理论上比任何异步复制都快。另外切换非常灵活今天可以只让10%的消息打到新集群观察稳定后再加大比例。但缺点也必须提前想清楚。第一业务代码一定要改如果系统里几十个服务都在直连Kafka改造成本会很高。第二消息重复不可避免。两条链路都可能出现部分成功的情况比如新集群写失败但旧集群写成功了下游消费时如果不做幂等必然会有重复消息。第三双倍流量会对生产链路和下游造成额外压力一些对延迟敏感的核心链路需要评估是否承受得住。实际操作时我习惯在Producer外面包一层路由底层还是原生的KafkaProducer只是发送前根据路由规则复制一份到另一个Producer实例。这里有个很容易踩的坑两个集群都写失败时怎么办降级策略一定要提前定好。我的经验是新集群写失败只记录日志和指标不影响主链路旧集群写失败则直接抛异常触发原有告警因为那才是当前真正在用的链路。双写方案适合业务可改造、迁移时间充裕、希望全程能灰度控制的团队。它不适合那种几十个老系统都直连Kafka、代码已经没人敢动的场景那种场景还是老老实实用MirrorMaker。2.2 MirrorMaker 2跨集群复制的官方方案如果你不想改业务代码那MirrorMaker 2简称MM2基本是首选。它是Kafka官方自带的跨集群复制工具从2.4版本开始就是标准答案。它的本质是一个跑在Kafka Connect框架上的应用用内置的Source Connector消费源集群的Topic再通过内置Producer把数据写入目标集群。MM2比老版MirrorMaker强的地方在于它不只是复制数据还会同步消费组offset、Topic配置、ACL等元数据。特别是checkpoint机制它会定期把源集群消费组的位点记录到目标集群的专用Topic里。这个能力对迁移来说非常关键它决定了你切换消费者后能不能从旧集群的断点继续消费而不是从头消费或者从末尾消费。用MM2做迁移的最大优势就是业务零改造不用碰任何Producer和Consumer代码只要部署一个MM2进程就能把整条数据管道搭起来。同时它支持双向复制也符合容灾演练的场景。缺点方面MM2是异步复制目标集群数据始终存在一定延迟几秒到几十秒都有可能具体取决于网络和负载。此外复制过程中也可能产生重复消息下游消费最好有幂等兜底。如果只是迁移需求我通常只开单向往目标集群复制不开反向。双向复制在容灾场景才有意义迁移阶段开双向容易造成消息循环给自己增加不必要的复杂度。2.3 分区重分配集群内节点迁移的正确打开方式这里单独说一下集群内节点替换的场景。很多人一听到迁移就想到跨集群复制其实如果只是要换掉某几个broker用Kafka原生的分区重分配工具就够了完全不需要MirrorMaker。原理上kafka-reassign-partitions.sh会把指定分区的数据在broker之间做增量复制等新副本追平到leader之后切换leader再删除旧副本。整个过程是在线完成的不需要停机但会在迁移期间产生额外的磁盘和网络IO。所以我的建议是尽量在业务低峰期执行并且用--throttle参数限速比如限到50MB/s避免把集群IO打满。操作流程一般是三步。第一步用kafka-reassign-partitions.sh --generate生成候选迁移方案它会根据当前分配情况输出一个JSON分配方案第二步把方案改到只包含你想迁移的Topic和分区然后用--execute执行第三步用--verify观察迁移状态直到所有分区都显示completed。这里有个重要经验重分配一个批次不要挪太多分区一批一批来。你一次把所有分区都搬过去中间某个节点挂了整个集群的稳定性都会受影响。我习惯一次最多挪几十个分区跑完一批确认稳定再做下一批。整个过程虽然慢但稳。2.4 如何选停机窗口、一致性、改造成本方案选型的核心就三个变量停机窗口、数据一致性要求、业务改造成本。我整理了一个简单的对比表方案停机时间业务侵入数据一致性复杂度适用场景冷拷贝停写需要无高低允许停机的小集群应用双写不需要高中可能重复中业务可改造、可灰度MirrorMaker 2不需要低中异步中高整体跨集群迁移分区重分配不需要无高低集群内节点替换如果停机窗口比较富裕其实可以选最土的冷拷贝方案停掉所有生产写入把Kafka数据目录或者用工具搬迁存量数据然后在新集群启动消费。这个方案数据一致性最高操作也最简单问题就在于业务要能接受停机时间哪怕只有十几分钟也不是所有系统都扛得住。生产环境多数不能接受长时间停机所以“MirrorMaker 2/双写 消费组offset同步”是主流组合。面试时如果被问到Kafka怎么做迁移先问清楚能不能停机、要不要改代码、是跨集群还是集群内换节点然后再给方案基本就能加分。高手不是会敲一条命令而是会做方案取舍。3. 实操用 MirrorMaker 2 做一次跨集群迁移3.1 环境准备本地 Windows 快速搭一套测试集群很多同学本地是Windows想先搭一套环境验证方案。Kafka官方其实没有提供Windows安装包但二进制包解压后是可以直接跑的只要把JDK配好。Kafka 3.x以上推荐用KRaft模式不用装Zookeeper比很多老教程舒服得多。步骤不复杂。先下载Kafka二进制包比如kafka_2.13-3.6.2解压到C:\kafka。然后把JAVA_HOME指向JDK 11或17PATH里加好bin目录。接着编辑config\kraft\server.properties关键配置改成这样process.rolesbroker,controller node.id1 listenersPLAINTEXT://localhost:9092,CONTROLLER://localhost:9093 advertised.listenersPLAINTEXT://localhost:9092 controller.quorum.voters1localhost:9093然后打开命令行先执行bin\windows\kafka-storage.bat random-uuid生成一个集群ID保存下来。再执行bin\windows\kafka-storage.bat format -t uuid -c config\kraft\server.properties格式化存储目录最后用bin\windows\kafka-server-start.bat config\kraft\server.properties就能把单节点Kafka跑起来。想模拟新旧两个集群就再复制一份目录把server.properties里的node.id改成2端口改成9192和9193再格式化启动一次。两个本地集群就能跑通后面的MM2流程。Windows下有几个常见坑路径带中文会报错JDK版本太老起不来改了listeners但忘了改advertised.listeners会连接失败。这些细节排查起来很耗时间。这里的重点是搭一个能复现迁移流程的测试环境不是为了性能验证。生产环境还是建议Linux裸机或容器化部署Windows当个验证工具足够了。3.2 MirrorMaker 2 的配置与启动步骤本地假设有两个集群source监听localhost:9092target监听localhost:9192。我们需要把source的Topic复制到target。新建一个mm2.properties配置文件核心内容如下clusters source, target source.bootstrap.servers localhost:9092 target.bootstrap.servers localhost:9192 # 单向复制source - target source-target.enabled true source-target.topics .* target-source.enabled false # 自动创建目标集群Topic source-target.topic.auto.create true # 同步消费组offset source-target.emit.checkpoints.enabled true source-target.sync.group.offsets.enabled true启动命令是bin/kafka-mirror-maker2.sh config/mm2.propertiesWindows下就是bin\windows\kafka-mirror-maker2.bat。启动后到target集群里看会发现多了一批新Topic名字默认带source.前缀比如source.orders。这个前缀是MM2故意设计的目的是防止双向复制时消息循环。但对迁移场景来说我们通常希望目标集群的Topic名和源集群完全一致这样客户端切换配置时最省事。要实现这一点需要自定义一个ReplicationPolicy。写一个Java类继承DefaultReplicationPolicy重写formatRemoteTopic方法import org.apache.kafka.connect.mirror.DefaultReplicationPolicy; public class NoPrefixReplicationPolicy extends DefaultReplicationPolicy { Override public String formatRemoteTopic(String topic) { return topic; } }编译成jar放到Kafka安装目录的libs下然后在mm2.properties里指定replication.policy.classNoPrefixReplicationPolicy。这样复制出来的Topic名就和源集群一致了。这里必须提醒一句一旦用了无前缀策略千万别再开双向复制否则两个集群互相复制消息会无穷循环。单向复制不受影响。另外Topic比较多时建议先用正则限定范围比如source-target.topics orders\|payment\|user_events验证没问题后再放开全量避免一开始就复制一些不需要的Topic。3.3 验证数据完整性消息数、位点、时间戳复制跑起来之后最容易被忽视的就是验证环节。我见过有人启动MM2后看到两边Topic都存在就宣布迁移成功结果过几天业务方发现有消息对不上因为某些分区offset没追上。第一层验证是对比各分区offset。在source集群执行bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic orders --time -1target集群也执行相同命令然后把每个分区的log end offset逐行对比。更稳一点的做法是写个脚本先拿每个分区的log start offset再拿log end offset两者之差就是该分区的消息总量然后两端对比。注意不要只看总和分区粒度上的对比才能暴露具体是哪个分区出了问题。第二层验证是抽样比对消息内容。用console consumer把部分分区的消息导出或者写一个简单的Kafka Consumer对每条消息的key和value做哈希放到一个Map里再对另一端做同样操作比对是否有差异。抽样不需要全量但每个分区都要覆盖到。这一步能发现offset对得上但内容不对的场景比如序列化问题或者复制链路中间处理逻辑有问题。第三层验证是消费端位点。在source集群查看业务消费组的当前位点bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-consumer-group如果MM2的checkpoint同步开启target集群会有一个同名group.id的消费组位点应该接近source。这个值决定了切换消费者后能不能从旧集群断点继续消费。实操心得MM2是异步复制目标集群总会比源集群慢几百毫秒甚至几秒这是正常现象。验收标准不要写成“两边完全一致”而是定义“差距在可接受范围内且不持续增大”比如5秒以内就算通过。3.4 流量切换与客户端割接数据校验通过后进入切换环节。这里的顺序非常重要我强烈建议先切消费者后切生产者。为什么不能先切生产者因为如果先把生产者切到新集群旧集群的消费者还在旧集群消费新写入目标集群的消息旧消费者完全看不到业务直接就断了。反过来先切消费者因为MM2持续把源集群新消息同步到目标集群消费者切过去后虽然可能短暂滞后但很快会追平。具体操作分四步。第一步确认target集群已有同名消费组并且offset与source集群接近这样才能续接消费位点。第二步把消费者客户端的bootstrap.servers从旧地址改到新地址分批灰度切换改完后立刻观察新集群这个消费组的lag确认是从同步的位点继续消费而不是从头或从尾部开始。第三步消费者全部切完并稳定后再切生产者同样分批灰度。第四步全部切完后MM2可以继续运行一段时间作为备份链路但要注意复制方向不能开反向否则会产生循环复制。这里有个很常见的坑消费者切过去后发现位点不对从开头开始消费了。原因一般是sync.group.offsets.enabled没开或者源目标和客户端里的group.id不一致或者目标集群这个group之前被手动消费过导致checkpoint失效。检查这三个点基本能定位。切换过程中如果用了自定义ReplicationPolicy去掉了Topic前缀还要注意一点客户端不能同时连接两个集群去订阅同一个名字的Topic元数据会互相覆盖导致路由混乱。所以切换期间最好是同一进程内只指向一个集群不要新旧集群地址同时挂在同一个客户端配置里。4. 迁移中的兼容性与坑大消息、延迟、版本差异4.1 单条 1MB 大消息的配置与验证搜索Kafka相关问题时经常能看到类似“kafka 接收1m”的关键词这说的就是Kafka默认单条消息大小上限是1MB。很多业务在迁移阶段才暴露出这个问题旧集群可能早就被运维调大了参数新集群还是默认值一切过去立刻报RecordTooLargeException。需要对齐的参数有好几层我先列个表位置参数默认值调整方向brokermessage.max.bytes1048576调到目标单条上限如10485760brokerreplica.fetch.max.bytes1048576必须大于等于message.max.bytesbrokersocket.request.max.bytes104857600按需调大producermax.request.size1048576大于等于单条消息上限consumermax.partition.fetch.bytes1048576大于等于单条消息大小consumerfetch.max.bytes52428800按批量消费需求调整我经常看到有人只改了broker的message.max.bytes忘了改replica.fetch.max.bytes结果副本同步时一直报错副本长期处于UnderReplicated状态。这两个参数必须一起调整。验证方法很简单写一段Producer代码发送一条2MB的字节数组到目标集群能正常发送、能被消费参数才算配好Properties props new Properties(); props.put(bootstrap.servers, localhost:9192); props.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer); props.put(value.serializer, org.apache.kafka.common.serialization.ByteArraySerializer); props.put(max.request.size, 10485760); ProducerString, byte[] producer new KafkaProducer(props); byte[] bigPayload new byte[2 * 1024 * 1024]; producer.send(new ProducerRecord(orders, migration-key, bigPayload)).get(); producer.close();迁移前把新旧集群这套参数全部对齐并实际用大消息测一遍能节省非常多线上排障时间。图片、日志大字段、埋点大JSON在真实业务里非常常见不是极端场景。4.2 迁移后消息延迟变高的排查思路切到新集群后业务反馈“消息延迟高”是高频问题。出现这种情况不要急着怪新集群性能差先按环节拆解到底是生产者到broker慢还是broker到消费者慢。我排查时会先看broker的CPU、磁盘IO、GC。磁盘IO是很多迁移翻车的地方旧集群用了SSD新集群却配了普通HDD顺序写差距可以达到好几倍。然后是生产者侧指标batch size、linger.ms、compression.type、acks。acksall时如果副本数从2变成了3确认时间自然会变长linger.ms0时小消息每一条都单独发送网络往返成本非常高。消费者侧要关注max.poll.records、max.poll.interval.ms、session.timeout.ms。消费者处理不过来lag就会涨整体表现就是消息延迟高。还有一个特别隐蔽的坑跨机房网络。新旧集群不在同一个机房时客户端切换后的RTT会明显上升尤其是同步发送加acksall延迟直接翻倍。物理距离带来的延迟不是调参能完全消除的尽量让新旧集群在迁移窗口内处于同一网络区域或者至少用专线打通。我整理了一个快速排查表现象可能原因查找方式对策producer send耗时高linger.ms太小/batch太小producer metric batch-size调整batch.size和linger.ms考虑开启压缩消费lag持续涨消费者处理慢/分区不够kafka-consumer-groups --describe增加消费者实例或分区优化消费逻辑副本同步异常replica.fetch参数没对齐kafka-topics --describe 看ISR对齐大消息相关参数端到端延迟大网络RTT高/跨机房ping、专线路由监控迁移期间尽量同机房或调整生产者确认模型另外还有一个现象客户端改了bootstrap.servers指向新集群后可能还连着一部分旧broker。这是因为客户端会缓存元数据不会立刻丢弃旧的broker连接。出现这种情况时最直接的办法是重启消费者进程等metadata刷新后再观察。4.3 客户端版本兼容与序列化迁移前还要盘一下所有客户端的Kafka版本。Kafka服务端对老客户端有兼容性策略但也不是无底线地兼容。0.10.2以上的客户端连3.x基本没问题0.9或者更早的版本新集群默认可能会拒绝老协议。除了协议版本消息格式也是一个隐蔽问题。新集群默认消息格式是v2如果你的消费者仍然是老版本kafka-client并且没有做兼容设置可能出现反序列化或CRC校验问题。稳妥做法是迁移前把客户端统一升级到0.11以上如果确实无法升级可以在新集群设置log.message.format.version为旧版本对应的值但这个参数在新版本中有废弃趋势终归要升级客户端。序列化方面容易被忽略。Kafka本身不关心消息内容格式但迁移验证时如果你按JSON或AVRO去解析就必须确保新旧两边的schema一致。特别是用了Confluent Schema Registry的场景新集群客户端需要指向新的registry地址同时把schema同步过去否则消费者反序列化直接报错。我在实际迁移中一定会做一张“客户端清单”列清楚每个服务用的kafka-clients版本、序列化方式、是否使用Schema Registry、消费组ID是什么。别嫌这张表麻烦等出了问题再去翻代码成本翻十倍都不止。5. 迁移后的观测与运维UI界面、监控、性能对比5.1 Kafka UI 工具推荐顺带回答那个高频问题Kafka有没有UI界面答案是不仅有而且选择非常多。迁移验证阶段我肯定会装一个UI直观看到新旧两个集群的Topic、分区和消息情况比敲命令行舒服很多。常见选择工具类型特点适用场景Kafka UIWeb多集群、消息查看、consumer管理社区活跃日常运维首选Offset Explorer桌面客户端查看Topic、分区、offset非常方便本地快速调试KafdropWeb轻量看消息直观临时排查CMAK (Kafka Manager)Web老牌管理工具偏集群管理老版本集群迁移期Prometheus GrafanaWeb监控指标监控必备生产环境告警经验提醒生产环境的UI工具建议只做只读用途不要在UI里直接改Topic配置、删消费组。这些操作很容易误点尤其Kafka UI新版本交互改动频繁我见过同事点错按钮把消费组重置了的情况。要改配置还是用命令行加权限控制比较稳妥。5.2 监控指标与性能对比迁移完成后不是看一眼lag能消费就算完。正确姿势是建立一套核心指标监控把新旧集群迁移前后做个对比确认新集群确实承接住了原流量。重点盯这几个指标BytesIn/BytesOut表示集群吞吐确认有没有流量异常MessagesInPerSec是每秒消息数和业务预期对照RequestHandlerAvgIdlePercent是请求线程空闲率长期低于30%说明broker线程快被耗尽需要调大num.io.threadsNetworkProcessorAvgIdlePercent同理。UnderReplicatedPartitions是副本同步落后分区数长时间大于0说明某台broker写入慢或网络有问题OfflinePartitionsCount必须是0IsrShrinksPerSec和IsrExpandsPerSec如果频繁跳动说明broker性能波动大。用Kafka exporter配合Grafana模板就能搭一套不用自己从零画图。迁移后第一天要重点盯UnderReplicatedPartitions和IsrShrinksPerSec因为新集群的副本同步往往是最弱的环节。性能对比也可以用压测脚本验证。Kafka自带工具bin/kafka-producer-perf-test.sh --topic orders --num-records 1000000 --record-size 1024 --throughput 10000 --producer-props bootstrap.serverslocalhost:9192 linger.ms10 batch.size65536bin/kafka-consumer-perf-test.sh --bootstrap-server localhost:9192 --topic orders --messages 1000000 --reporting-interval 1000压测前先确认Topic分区数足够如果分区数太少吞吐会被单个分区上限卡死。压测结果不一定代表生产真实水平但用来做新旧集群的横向对比很有参考价值。5.3 迁移验收与回滚兜底验收维度我习惯列一个清单逐项打勾。新旧集群各项Topic配置要一致包括分区数、副本数、retention、cleanup.policy、min.insync.replicas。新旧集群各分区offset差值要低于设定阈值。业务消费组在新集群运行正常lag稳定在低位。核心链路场景要人工验证通过比如下单、支付回调、报表任务这些真实业务动作不能只看监控。监控告警全部切换到新集群旧集群告警可以保留但降噪。再说回滚。我的原则是旧集群不要急着下线。最稳的回滚策略是保留旧集群和复制链路至少一个完整保留周期假设retention设置的是7天就留满7天。如果切换后发现问题生产者切回旧集群消费者也切回旧集群位点还在业务能迅速恢复。新集群这段时间积累的数据可以手工补数尽量减少损失。回滚期间最忌讳的操作是删Topic、删消费组、清空offset。这些动作一旦做了旧集群就真的回不去了。所以下线旧集群前一定要让负责人确认数据已确认完好业务已稳定运行超过一个保留周期再动手清理。还有一个小细节迁移结束时MM2进程不要用kill -9粗暴停掉。如果你还在用默认复制策略它可能正在运行checkpoint同步直接杀掉容易留下未完成的内部状态Topic。正确做法是先把mm2.properties里的复制开关改成false或者停掉connect任务等内部状态Topic清理完再退出进程避免下次启动时出现offset错位。最后数据校验脚本千万别删留在团队里。每次迁移或者大版本升级都可能用得上。我自己的体会是Kafka迁移真的不是看谁命令敲得熟而是看谁能把停机窗口、数据校验、回滚预案这些“脏活”想在前面。把这套思路掌握住迁移过程再复杂心里也不会慌。
