先说我自己的感受我维护Kafka集群的时间不算短但真正让我下决心研究KRaft的是一次ZooKeeper集群抖动。当时Kafka本身很稳可ZooKeeper三个节点之间的网络延时稍微变大整个集群的元数据读写跟着卡顿分区leader的变更也像被按了暂停键。那会儿群里都在说“Kafka要抛弃ZooKeeper”我第一反应是这不就是把注册表换掉吗真研究完才发现这是一个从“两套分布式系统互相牵制”到“一套Raft协议统一元数据”的底层架构重构。如果你只在Kafka 2.x时代装过集群或者面试时被问过“Kafka为什么要去ZooKeeper”这篇文章值得看完。我会把ZK在旧架构里到底扮演什么角色、KRaft换掉了什么、自己搭一个KRaft集群会遇到哪些坑以及老集群怎么迁移按实际操作过的思路拆开讲。1. 旧架构里的ZooKeeper不只是“注册中心那么点事”很多人一听到“Kafka依赖ZooKeeper”就自动脑补成“ZooKeeper就是个存元数据的注册中心”。这个理解不算错但远远不够。因为在Kafka 2.x及更早的架构里ZooKeeper不只是保存一份配置它还是Kafka集群可用性的“仲裁者”。Kafka自己是一个分布式的流处理平台但它内部的控制器选举、副本状态流转、分区的元数据变更全都要依赖ZooKeeper来协调。1.1 Kafka把哪些关键状态塞进了ZooKeeper我用一个Kafka 2.5集群做过实际故障演练为了搞清楚ZK里到底有什么专门去查过路径。简单说旧模式下这些数据都在ZooKeeper里Broker注册信息每个broker启动后会往ZK写一个临时节点路径类似/brokers/ids/{brokerId}里面记录当前broker的地址和端口。一旦broker和ZK的会话超时这个临时节点会消失其他broker和controller会认为这个节点已经挂了。主题和分区分配创建topic时分区和副本分配关系会写入/brokers/topics/{topic}。消费者和生产者拿到元数据也是从broker侧间接依赖ZK里的这些分配信息。Controller的选举整个Kafka集群会有一个controller主要负责分区leader的选举、副本集合ISR的更新、分区重分配等管理操作。这个controller不是Kafka自己选出来的而是通过ZooKeeper上的临时节点竞争实现的——谁先成功创建/controller节点谁就是controller。ISR列表的变更当一个副本落后太多leader要把这个副本从ISR里移除或者当副本重新赶上时要加回来这些变更在旧架构下要写ZK节点。ACL和配额等配置权限相关的/kafka-acl、客户端配额的/config/clients等路径也都在ZK里。所以Kafka对ZooKeeper的依赖其实是“控制平面完全外包”的状态Kafka只管把消息数据写到自己的Log里至于我的leader是谁、有哪些副本活着、分区应该怎么分配这些决策逻辑虽然在Kafka controller里执行但决策所需的“状态存储”和“选举保障”却在另一个系统里。1.2 两套分布式系统互相牵制稳定性最难受的点一旦理解了这种架构你就会明白为什么Kafka集群故障里有一种特别典型的连锁反应ZooKeeper抖动Kafka很无辜地跟着遭殃。举个例子Kafka的controller在检测到某个broker下线时会把该broker上的分区leader重新分配到其他broker上。这个过程需要先和ZooKeeper交互把ISR、leader等信息更新过去。如果ZK此时出现了会话超时、节点频繁重新选举controller就会陷入“不停尝试写元数据但写不进去”的状态。我见过一个三个broker的小集群ZK那么小按理说负载不高但因为ZooKeeper节点之间的磁盘同步延迟导致Kafka的controller频繁切换客户端那段时间连最基本的ListOffsets请求都可能超时。更麻烦的是Kafka自己已经是一个高吞吐的分布式系统但它选用的ZooKeeper却是一个更通用的分布式协调服务。它需要处理自己的quorum、自己的日志同步、自己的会话管理。相当于你原本只需要一辆卡车结果你雇了一个车队来管司机的排班还得让卡车和车队的指挥中心时刻保持心跳。只要车队的调度出问题卡车就算油箱满着也跑不了。1.3 写入瓶颈和脑裂风险早晚要面对ZooKeeper模式还有一个长期被吐槽的瓶颈元数据写放大。在旧架构里每个broker启动、每个topic创建、每个分区的ISR变化都是一次ZK写入。ZK的写入能力受限于单Leader节点的处理速度因为ZK本质上是一个通过Zab协议复制状态的一致性系统所有写请求最终都要过Leader。Kafka集群规模一大topic数量一多分区数量到数万之后ZK集群的压力会明显上升。你可能会想ZooKeeper不是也能横向扩容吗但它是A可读节点和C一致性的权衡增加follower节点并不能提升写吞吐反而会让Leader同步日志的开销更大。脑裂风险也是个很难忽视的话题。旧架构里的ZooKeeper集群如果发生分区可能会出现多个ZK节点都认为自己能提供服务而从Kafka侧看它靠ZK的quorum来判断哪个controller是有效的。虽然ZK本身通过多数派避免了真正的“双主”写入但分布式系统的网络分区不可能完全消除任何依赖独立协调器的架构都会多出一层不确定因素。KRaft把所有Kafka集群控制器的选举和元数据日志统一交给Kafka自己内嵌的Raft协议处理等于把对外部系统的判断收回到引擎内部。2. KRaft到底换掉了什么不是简单把ZK换成另一套注册中心刚开始接触KRaft时我差点犯一个错误以为KRaft就是把ZooKeeper换成一个内嵌的etcd或者Consul。实际看KIP-796和后续设计才明白KRaft是让Kafka自己承担元数据的存储和复制并且把所有controller相关的状态机抽象成一条元数据日志。它的核心是“自己管自己”而不是再外包一个协调服务。2.1 Controller Quorum一群controller节点用Raft协议形成决策组在KRaft模式下Kafka集群里会有一个由若干controller节点组成的组官方叫Controller Quorum也可以理解成决策小组。这个组和ZooKeeper最大的区别在于状态不在“外部”而是在元数据日志里。每个controller节点都会维护一份元数据日志这些节点通过Raft协议选举出一个Active Controller过去叫leader controllerKRaft里依然沿用leader的概念。所有Kafka的集群级元数据变更比如创建topic、修改配置、broker上下线、分区leader切换都会先写进这条元数据日志然后通过Raft在controller节点之间复制只要多数派节点确认写入成功这次变更就算提交了。broker节点本身也会订阅/拉取这份元数据日志的变更然后更新本地缓存从而知道“我现在要承担哪些分区”。如果把旧架构比作“Kafka在外面跑业务数据ZooKeeper在另一个房间管状态”那么KRaft就是“Kafka的业务日志旁边多了一条元数据日志控制决策和执行逻辑都在同一个进程组里”。2.2 为什么偏偏是Raft而不是继续用Paxos/Zab分布式一致性协议不少ZooKeeper用的Zab其实也是类似思路ETCD用的Raft那Kafka为什么选择自研一套基于Raft的元数据协议我理解有几个现实原因。第一Raft的设计目标就是“可理解性”。相比PaxosRaft把问题拆成leader选举、日志复制、安全性三个相对独立的模块对于Kafka这个计算密集型系统团队可以更快地把它改造成专门适配Kafka元数据场景的协议而不是把一个通用协调服务整体搬进来。第二Kafka需要一个“能直接把元数据当作事件流处理”的机制。Raft的复制日志本质上就是一条有序的变更记录而Kafka最擅长的就是处理顺序日志。所以KRaft的controller把元数据日志看成一种特殊的事件流每次变更都是一个元数据事件。Kafka团队不仅做了一个协议还顺带做了一个基于事件溯源的元数据状态机当前集群状态不是从ZK的树节点反推而是通过重放日志得到。第三去掉ZooKeeper之后controller节点的多副本能力和分区副本的管理可以共享同一套复制机制思路。运维上只需要维护一种一致性日志比“Kafka一边跑自己的副本同步另一边还要维护ZK的Zab复制”要简单得多。2.3 事件溯源和MetadataVersionKRaft里的“日志即状态”KRaft的元数据日志看起来很像Kafka的普通消息日志每个controller节点会在本地存储分区的元数据快照snapshot和增量变更段segment。启动时如果本地没有状态就从最新快照开始加载再重放之后的增量日志直到追上当前状态。这个过程就是最常见的事件溯源event sourcing形态。所以KRaft模式下一个非常重要的概念是MetadataVersion。Kafka的元数据日志有一套自己的版本演进机制比如不同版本支持的元数据记录格式不同。也就是说把老集群从ZooKeeper模式迁移到KRaft模式时并不是“把ZK数据倒一遍”就完事而是要确保当前Kafka版本能理解老版本的元数据格式。这也是为什么社区一直强调做迁移前先把Kafka版本升级到官方支持迁移的版本而不是在老版本上强行迁移。有朋友问我“那KRaft是不是可以完全不用ZooKeeper了”对新集群从搭建开始就不需要部署ZooKeeper。而且到了Kafka 4.x官方已经正式移除ZooKeeper支持也就是说你会看到Kafka发行包里连那些ZooKeeper相关脚本都不再维护了。还在用2.x集群的同学这个问题不是“要不要解决”而是“什么时候解决”。3. 亲手搭一个KRaft集群配置和踩坑理论说太多不如实际搭一次。我在本地用三个节点搭过一个“1个controller节点混跑broker 3个纯broker节点”的KRaft集群也经历过格式化失败、集群ID不一致导致controller quorum起不来之类的坑。这里给出一套可以直接照抄的操作流程。3.1 先理解两种节点角色combined和isolatedKRaft模式下一个进程可以承担角色broker、controller或者两者都承担。在单机实验或中小集群里常见的是process.rolesbroker,controller也就是“一个节点同时当broker和controller”。这种模式叫combined模式部署简单省机器适合开发、测试和规模不大的生产环境。但如果你要追求更好的隔离性应该把controller单独部署也就是process.rolescontroller和process.rolesbroker分开。这样controller的负载不会和broker的消息读写争抢资源controller节点出问题也不会直接影响broker的网络连接。生产环境条件允许的话我建议用3个独立controller节点broker节点再按需扩展。3.2 单节点快速起一个KRaft集群我以Kafka 3.x的二进制包为例先手动搭建一个单机combined模式。整个过程比ZooKeeper模式少了两步不用单独启动ZooKeeper也不用把ZooKeeper地址配到server.properties里。先创建一份配置文件假设叫config/kraft/server.propertiesprocess.rolesbroker,controller node.id1 controller.quorum.voters1localhost:9093 listenersPLAINTEXT://localhost:9092,CONTROLLER://localhost:9093 inter.broker.listener.namePLAINTEXT advertised.listenersPLAINTEXT://localhost:9092 controller.listener.namesCONTROLLER listener.security.protocol.mapCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL log.dirs/tmp/kraft-combined-logs num.partitions3 default.replication.factor1 offsets.topic.replication.factor1 transaction.state.log.replication.factor1 transaction.state.log.min.isr1这里几个配置有必要解释一下process.roles声明了当前节点的角色不能留空。node.id在整个Kafka集群中唯一。如果三个controller节点都用1Raft协议根本组不了quorum。controller.quorum.voters格式是{nodeId}{host}:{port}多个controller之间用逗号分隔。启动之前必须保证这里配的节点和实际启动的controller节点一致。controller.listener.names和controller.quorum.voters里的端口要对应上controller内部通信和外部请求走的不是同一个监听器。然后用命令生成集群ID并格式化日志目录KAFKA_CLUSTER_ID$(bin/kafka-storage.sh random-uuid) bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties注意format会清理log.dirs里已经存在的栗子数据。如果你只是想重新初始化环境记得先备份日志目录。格式化成功之后再启动bin/kafka-server-start.sh config/kraft/server.properties启动日志里能看到类似“Registered broker”、“Transitioning to leader”之类的信息说明controller quorum已经建立。3.3 三节点KRaft集群的角色划分和配置模板单机只是热身。如果你有三台机器我建议这样分三台机器都跑controller角色同时前两台也跑broker角色或者全部单独跑看资源。三节点combined配置里每台机器的controller.quorum.voters都要填三个controller的地址但每个节点自己的node.id和listeners各不相同。比如假设三台机器分别叫kafka-1、kafka-2、kafka-3controller端口都用9093broker端口用9092。那么kafka-1的配置大致是process.rolesbroker,controller node.id1 controller.quorum.voters1kafka-1:9093,2kafka-2:9093,3kafka-3:9093 listenersPLAINTEXT://kafka-1:9092,CONTROLLER://kafka-1:9093 advertised.listenersPLAINTEXT://kafka-1:9092 inter.broker.listener.namePLAINTEXT controller.listener.namesCONTROLLER listener.security.protocol.mapCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL log.dirs/data/kraft-combined-logskafka-2的node.id2kafka-3的node.id3host改成各自主机名其他保持一致。三台机器都要先执行一次random-uuid拿到同一个集群ID因为同一个集群必须使用同一个$KAFKA_CLUSTER_ID做格式化。这点极其容易出错有人图方便在每台机器上各自执行random-uuid结果每台机器格式化的集群ID不同启动后controller之间永远无法形成quorum。3.4 启动前必查的配置细节我踩过不少KRaft启动的坑总结成四件事第一同一集群内集群ID必须一致。如果启动后日志一直卡在等待controller连接优先检查kafka-storage.sh format用的集群ID是否一致。第二监听器端口不能让controller和broker共用。我见过有人为了省事把listeners写成PLAINTEXT://host:9093,CONTROLLER://host:9093结果broker间通信和controller通信端口冲突启动时直接报地址占用。controller端口最好独立于broker端口比如9093给controller9092给broker。第三advertised.listeners要写客户端和broker实际能访问的地址。云服务器场景里如果内部IP和公网IP不一致写错会导致客户端能连上但取不到分区元数据。第四格式化命令执行前确认log.dirs目录里没有重要数据。KRaft的format不是“增量初始化”它会清掉目录内容。特别是你想保留原ZooKeeper集群数据的时候一定不要手滑直接跑format要按官方迁移流程走。4. 从ZooKeeper迁移到KRaft不是重搭集群是“换引擎”新集群用KRaft很简单但老集群怎么迁是大家更关心的。我在一个测试集群上做过一次完整演练整体感觉是迁移不是不能做但比“导个配置”复杂得多必须分阶段走。4.1 先别急着迁移确认版本和兼容性首先明确一点不是所有Kafka版本都支持从ZooKeeper直接迁到KRaft。早期KRaft只能用于新集群老集群想迁过去要么升级到官方支持迁移的版本要么就得重建集群。我在测试时用的是Kafka 3.x的较新版本官方迁移工具已经支持读取ZooKeeper元数据并生成KRaft元数据镜像。到Kafka 4.x之后ZooKeeper模式本身被彻底移除所以老版本集群至少要先升到3.x再迁移。迁移前必须检查几样东西集群里有没老得离谱的topic配置比如使用某些自定义分区分配策略。是否还有客户端依赖Kafka的ZooKeeper连接极少见但有些老监控工具会直接连ZK看分区。磁盘空间是否充足因为迁移过程要额外写入元数据文件和临时快照。4.2 迁移的核心阶段以我实际理解的官方迁移思路整个流程大致是“先升级再生成元数据镜像再切换启动方式”。下面按步骤说但具体命令请以你所用版本的官方文档为准不要照抄版本号。第一阶段升级整个集群到支持迁移的Kafka版本保持ZooKeeper模式运行一段时间确认业务稳定。第二阶段准备KRaft的配置文件。和3.3节里的配置基本相同但需要参考官方迁移文档设置额外参数让节点知道当前ZooKeeper集群的连接信息。这个阶段不要直接改process.roles因为集群还是以ZooKeeper模式运行。第三阶段正式执行迁移工具。大致逻辑是把ZooKeeper里的元数据导出来转成KRaft元数据日志的格式然后格式化每个broker的log.dirs。这里特别容易忽略的是迁移工具要求你提供一个“集群ID”和“metadata路径”列表写错任何一个迁移都会中断。第四阶段修改配置文件让controller节点以KRaft模式启动。此时可以逐步把ZooKeeper的停止顺序做好先停止ZK集群的写入口再启动KRaft quorum观察broker是否重新注册到新元数据引擎。我个人的建议是迁移过程不要在生产集群上边做边学。先在测试集群完整演练一遍记录每一步的耗时和异常输出再带着这个“作业指导书”去生产环境做窗口操作。因为涉及到元数据变更回滚如果已经做完format会有一定风险所以迁移前一定要确认备份策略。4.3 迁移后的验证清单迁移完成不等于高枕无忧。我列了一个自查清单可以当作参考用bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092确认broker能够正常响应。查看bin/kafka-metadata-quorum.sh describe --bootstrap-server localhost:9092这个命令可以显示KRaft controller quorum的状态确认active controller存在且跟随者节点在线。创建一个测试topic生产几条消息再消费回来验证数据面正常。检查监控面板确认ZooKeeper相关指标不再产生broker日志里不再出现ZooKeeper连接信息。逐步把客户端、监控、告警里对ZooKeeper的连接配置全部移除避免残留依赖。迁移之后其实还有一类隐蔽问题老监控脚本里写死了ZK地址如果迁移后ZK已经停掉这些脚本会一直打印连接失败告警。我在演练时吃过这个亏以为业务正常就结束了结果告警平台天天报一堆UnexpectedError排查半天发现都是监控脚本自己回连已关闭的ZooKeeper。4.4 什么时候不值得迁移不是所有Kafka集群都要立刻迁。如果集群规模很小、生命周期短、业务又不关键暂时用老版本维持现状也完全合理。但选新集群时我真的不建议再按ZooKeeper模式搭了因为从Kafka 4.x开始官方已经不维护ZK模式长期看这条路只会越来越窄。反过来如果集群里有大量的topic、分区和ACL迁移成本和风险会比较高。这时候可以先把Kafka版本升级到3.x最新稳定版在测试环境验证迁移工具再决定迁移窗口。就算一时不迁也要在技术规划里把“ZK淘汰”这件事排进去不然等到Kafka占的ZooKeeper老版本出现安全或兼容性问题时你会很被动。5. KRaft时代你还需要重新理解这些事KRaft不是一个“改动完就完”的功能它会改变你对Kafka运维和故障排查的若干习惯。我把部署KRaft后我重新理解的东西整理如下很多都是以前的ZooKeeper思维解决不了的新问题。5.1 三副本的意义变了controller quorum才是新的命门以前只要ZooKeeper节点数量够Kafka的controller选举看起来是安全的。KRaft模式下你要关注的是controller节点的数量和分布。如果整个集群只有1个controller节点那这个节点挂了整个集群的控制平面就瘫痪了。所以生产环境至少要有3个controller节点让多数派2个还能继续工作。更关键的是controller节点不应该和broker区域完全绑定。比如三个controller都在同一个机柜或者同一个云可用区一旦这个区域故障集群同样会失去控制能力。我在设计KRaft集群时会把controller节点散到不同的故障域里这和给数据分区做多副本的指导思想一样。还有一个容易被忽略的点元数据日志的存储磁盘也要有可用性保障。KRaft的controller节点把元数据日志写在log.dirs里如果磁盘故障这个controller节点可能无法参与quorum。虽然其他controller还能维持但在节点数偏少的时候任何一个controller失效都可能让集群进入“控制面不可用”的风险区。5.2 客户端代码基本不用改但运维脚本要改好消息是对生产者和消费者来说KRaft模式下Kafka的协议基本没有变化原来用的客户端代码和API照常工作。不需要因为从ZooKeeper迁到KRaft而重写业务代码。但运维侧的很多脚本和工具要改比如原来通过ZooKeeper查看broker、controller状态的脚本可能需要改成调用AdminClient或kafka-metadata-quorum.sh。有些监控系统用Kafka的JMX指标以前能看到ZK连接数KRaft模式下这些指标可能没了要换成ControllerQuorum相关的指标。一些老的Kafka管理工具如果只支持ZooKeeper模式在KRaft集群里可能无法正常工作选型时要注意。我们团队当时在监控面板里保留了好几块ZooKeeper相关的图表迁移后图表长期没有数据因为已经没有这个组件了。后来我们把指标重点换成了kafka.controller:typeKafkaController的指标和quorum相关指标才真正把握住集群健康度。5.3 面试和选型中的高频问题最近几年Kafka面试题里KRaft几乎成了必考话题很多问题本质上都是在考你有没有发现架构变化背后的原因。我整理几个常被问到的角度ZooKeeper被移除Kafka的Controller还是单点吗不叫单点而是有一个由Raft选出的Active Controller它挂了之后其他controller节点会重新选举但同一时刻只有一个leader处理写请求。KRaft能不能保证元数据写入不丢它靠Raft的多数派确认理论上只要多数controller节点正常元数据提交不会丢。生产者和消费者的offset还是存在Kafka内部topic吗对offset存储这件事从来不是ZooKeeper的职责消费者组的偏移量一直走内部topic存储所以KRaft不改变这个机制。选型时也会被问到“Kafka和RabbitMQ/RocketMQ怎么选”。抛开业务形态不谈KRaft之后Kafka的部署复杂度明显下降因为它不需要再绑定一套ZooKeeper集群。以前你自己部署Kafka等于同时维护Kafka和ZK两套一致性系统现在只需要维护一套Kafka集群。对高吞吐、大量topic、日志流场景Kafka的优势更聚焦而RabbitMQ在消息路由的灵活性和AMQP生态上依然有优势RocketMQ在事务消息和业务消息链路里也有一席之地。做选型对比时我会把“元数据引擎是否依赖外部组件”也放进评分表里KRaft会让Kafka在运维成本这一项扳回不少分。5.4 一类常见的连接异常InvalidReceiveException怎么查热词里有“Kafka报错org.apache.kafka.common.network.InvalidReceiveException: Invalid”我在KRaft集群里还真遇到过。表面上看这个异常像是网络接收的数据不符合Kafka协议。实践里的原因多半是“请求打错了端口”或者“监听器协议映射不对”。比如你把controller端口9093暴露到了公网或某个负载均衡器后面又有监控脚本把这个端口当成broker端口去连对方发过来的HTTP或者其他非Kafka协议请求就会在Kafka服务端触发InvalidReceiveException。还有一种情况是KRaft集群里不同的broker之间inter.broker.listener.name不一致导致broker间通信时使用了错误的安全协议也会出现类似异常。排查时我一般按顺序做先看报错来源是controller节点还是broker节点如果是controller日志里出现优先怀疑是不是有外部探活或客户端连错了端口。检查listener.security.protocol.map和inter.broker.listener.name确保broker间通信走的监听器和安全协议一致。如果用的是Nginx或负载均衡确认转发规则没有把其他协议的流量混到Kafka端口上。用bin/kafka-console-producer.sh --bootstrap-server测试正常生产能通就说明协议本身没问题问题大概率来自探测流量。这个排错思路其实和KRaft关系不大但在KRaft模式下更容易踩到因为集群里多了一组controller监听端口9093监控和运维工具如果用端口扫描“发现Kafka服务”非常容易把9093误当成Kafka数据端口。我现在的习惯是给Kafka的broker和controller端口都打上明确标识在监控系统里也不做全端口探测只显式配置已知的broker端口。这样一来KRaft新增的controller端口既不会影响监控也不会给自己制造一堆Mock异常报警。如果让我给还在ZooKeeper模式上的团队一个建议我会说新业务从KRaft起步老业务按官方迁移工具走一套演练流程然后选一个业务低峰窗口正式切。别怕KRaft带来的概念变化它把“外部协调”和“内部状态”搅在一起的历史包袱卸掉了长期看只会让Kafka的运维更简单。