Zookeeper在Kafka中的角色：控制面一致性与KRaft演进

1. Kafka都这么强了，为什么还非要挂个Zookeeper

如果你接触过Kafka，大概率经历过这个场景：安装Kafka集群时，必须先装一套Zookeeper，然后再启动Kafka Broker，控制台里打出一堆像“Creating /brokers/ids/0”“Subscribing to /brokers/ids/0”这种日志。刚上手的人很容易冒出同一个疑问：Kafka自己不是号称分布式消息队列、支持副本同步和故障转移吗，为什么还要依赖一个独立的Zookeeper？它到底在Kafka里干了什么？分布式一致性又是靠谁保证的？

这个问题，也是Kafka面试题里出现频率最高的几个点之一。因为很多人把“Kafka的分布式一致性”笼统地归功于Zookeeper，但实际上这句话只说对了一半。Zookeeper管的是Kafka集群的“控制面一致性”——集群里有哪些Broker活着、Controller是谁、Topic分区的元数据长什么样、分区Leader是谁。至于消息数据的副本同步、消费位移提交这类“数据面一致性”，靠的是Kafka自己设计的ISR机制、HW/LEO水位线以及事务协调器等协议，Zookeeper并不参与消息数据的复制。

这篇文章，我准备把Zookeeper在Kafka中的角色彻底拆开讲清楚。内容会覆盖Zookeeper自身的核心机制（ZNode、Watcher、ZAB协议）、它在Kafka集群里的四类典型应用场景、近两年KRaft模式替代Zookeeper的演进原因，以及我在实际集群运维中踩过的坑和面试常考的答题框架。无论你是准备Kafka面试、正在搭集群，还是维护着一套老集群想弄明白架构，这篇都可以直接当参考。

2. 先搞清楚Kafka的“分布式一致性”分几层

很多人一听到“分布式一致性”，脑子里就冒出CAP定理、Raft协议这些东西，然后很自然地把Kafka的副本同步也归到Zookeeper头上。实际上，Kafka这种消息中间件面对的一致性问题和ETCD、Consul这类KV存储不一样，它不是一个单一目标，而是分层的。

2.1 控制面一致性：集群拓扑和元数据，归Zookeeper管

第一层是集群拓扑和元数据的一致性。一个Kafka集群里有多个Broker节点，每个节点要随时知道：现在集群里有哪些Broker在线、各自地址是什么、哪个Broker是Controller、某个Topic有哪些分区、每个分区的副本是怎么分布的、Leader是哪个副本、ISR集合是哪些副本。这些信息如果只存在某个Broker的本地内存里，那节点一旦挂掉，整个集群就失去这个信息了；如果每个Broker各存一份，又会出现互相不一致的问题。

Zookeeper在Kafka里的第一个核心作用，就是把这份“到处都要参考、但绝对不能乱”的元数据放在一个统一的地方。Broker上线时创建临时节点，下线时临时节点自动消失；Controller的选举通过争抢临时节点完成；Topic分区的新增、副本分配结果也以持久节点的形式存下来。所有Broker都通过订阅Zookeeper上的节点变化来感知集群状态。

这也是Kafka选择Zookeeper作为元数据存储的根本原因：它需要一份“对外表现为单机一样”的数据，但这份数据又不能真的只放在一台机器上——否则那台机器挂了整个Kafka集群就废了。Zookeeper刚好满足这个需求，多节点复制数据、过半确认后提交，对外暴露的写接口只有一条全局顺序。

2.2 数据面一致性：消息不丢不乱，靠Kafka自己的协议

第二层才是真正和“消息”相关的一致性。一个分区有多个副本，Producer往Leader写入消息，Follower从Leader异步拉取数据，那么多个副本之间的数据什么时候算一致？消息会不会丢？消费者会不会读到已经提交但还没同步到所有副本的数据？

这一层的一致性，Zookeeper是完全不参与的。Kafka通过ISR（In-Sync Replicas）机制来管理：Leader维护一个保持同步的副本集合，Producer写入时根据acks参数决定是否需要等待ISR中的副本确认；所有副本通过HW（High Watermark）和LEO（Log End Offset）来协调“哪些消息可以被消费者看到”；开始于Kafka 0.11的Epoch机制，则解决了Leader切换后旧Leader写回旧数据而导致的乱序问题。

所以面试时如果被问“Kafka如何保证一致性”，先不要直接往Zookeeper上靠，最好先拆开讲这两层：控制面的元数据一致性由Zookeeper保证，消息面的副本一致性由Kafka的ISR+HW+Epoch机制保证。这个回答方式，比背一段话术要有区分度得多。

2.3 四层一致性需求对照

为了更直观，我把Kafka涉及的一致性需求归成一张表：

这张表看完你会发现，Zookeeper在Kafka里的角色很清晰：它管的是整个集群的“大脑状态”——谁在、谁当主、分区怎么分布、Leader是谁。它是Kafka集群的控制面基座，但不是消息数据的存储。后面所有章节，都围绕这张表展开。

3. Zookeeper凭什么能成为“一致性基座”：ZNode、Watcher与ZAB协议

要理解Zookeeper在Kafka里的应用，光知道“它存元数据”是不够的，还得知道它自身是怎么保证一致性的，否则你没法回答“为什么多个Broker同时去ZK注册，不会写乱”这种问题。

3.1 ZNode的四种基本形态

Zookeeper的数据模型是一棵类似文件系统的树，树上的每个节点叫ZNode。ZNode不是普通的文件，它有四种类型，组合起来能满足Kafka各种不同场景的需求：

• 持久节点：创建后一直存在，除非手动删除。Kafka里Topic的元数据节点就是持久节点，Topic不删，节点就一直在。
• 临时节点：创建后跟随创建它的客户端Session，Session结束（客户端宕机、心跳超时）后自动消失。Kafka里Broker的注册节点、Controller锁节点都是临时节点。
• 持久顺序节点：在持久节点的基础上，ZK会给节点名自动追加一个自增序号。这个特性常用于分布式队列、分布式锁的实现。
• 临时顺序节点：临时节点加自增序号，典型应用是分布式公平锁。

Kafka用得最多的是“持久节点存配置元数据、临时节点存存活状态”这个组合。

这里有个非常关键的设计细节：临时节点是绑在Session上的，不是绑在进程上的。Broker进程和Zookeeper之间的心跳断了，并不会立刻触发临时节点删除，而是要等Session超时。这意味着，Broker的“在线/离线”状态在ZK看来是有延迟的，超时设得越短，故障感知越快，但网络抖动时误判的概率也越大。这个参数后面在实战章节我会专门展开。

3.2 Watcher机制：一次性的状态通知

ZNode本身只是数据，真正让Kafka集群能“活起来”的是Watcher机制。客户端可以监听某个节点的数据变化、子节点列表变化、节点创建和删除事件。一旦触发，Zookeeper会把事件推送给客户端。

注意Watcher有两个关键特性：第一是“一次性”，事件推送后监听就失效，客户端如果要持续监听必须重新注册；第二是“不保证实时性”，ZK只会保证事件最终会发出来，不会保证客户端收到事件时数据一定是全局最新的。Kafka的Controller和Broker在实现上都会处理这类细节，比如收到事件后重新获取一次最新数据。

这也是Kafka集群不需要高频“轮询”ZK就能感知节点变化的原因。每个Broker在注册自己的节点后，会同时监听 /brokers/ids 下的子节点列表变化；一旦某个Broker宕机，其余Broker的Watcher会被触发，从而更新自己的元数据缓存。

3.3 ZAB协议：写请求只有一条全局顺序

ZNode和Watcher只是对外壳，Zookeeper内部的分布式一致性靠的是ZAB协议。ZAB全称Zookeeper Atomic Broadcast，和Raft不同，它是为Zookeeper专门设计的原子广播协议，核心思想可以用一句话概括：所有写请求都必须经过Leader，Leader给每个写请求分配一个全局递增的zxid，然后按序广播给Follower，超过半数的Follower确认后，请求才算提交成功。

zxid是个64位的数字：高32位是epoch，代表当前Leader的“任期”；低32位是按顺序递增的事务编号。每个新的Leader产生时，zxid的epoch部分会加一，这保证了旧Leader在任期内产生的日志即使被延迟，也不可能污染新Leader的日志。如果旧Leader网络分区后恢复，发现自己手里的zxid的epoch比当前Leader小，它就只能当Follower，不能继续接受写请求。

ZAB的写流程大致是：客户端把写请求发给任意节点；如果不是Leader，该节点会把请求转给Leader；Leader生成zxid并作为Proposal广播给所有Follower；Follower把事务写入本地日志后返回ACK；Leader收到过半ACK后提交事务，并向所有节点发Commit通知；最后Leader才向客户端返回写成功。

这个流程里有两个点值得停下来想一想。

第一，“过半”是怎么和“高可用”结合的。一个有2n+1个节点的集群，最多能容忍n个节点故障，因为剩下的n+1个节点仍然过半，可以正常提交事务。这也是为什么ZK集群节点数一定要是奇数的原因——并不是偶数不行，而是偶数会浪费一台机器的容错额度。比如4个节点和3个节点，容错能力都是最多挂1台，但4台比3台多付一份机器成本。

第二，客户端收到“写成功”返回之后，这个请求会不会因为节点故障而丢失？答案是：不会。因为ZK已经执行了“过半确认”，过半节点把事务写进本地日志了。即使Leader在返回后立刻宕机，新选出的Leader也会从这些过半副本中恢复日志，把已提交的事务补完整。反过来，如果一个写请求还没到“过半确认”阶段，Leader就挂了，那么客户端收不到成功返回，这个请求是不算数的，客户端可以重新发起。

3.4 ZAB的崩溃恢复阶段

ZAB协议分两个阶段：广播阶段和崩溃恢复阶段。广播阶段就是上面说的“Leader给Follower发Proposal、过半确认、提交”的正常流程；崩溃恢复阶段发生在Leader宕机、集群重新选主时。

崩溃恢复的核心是：新Leader必须保证“已经被提交的事务不能丢，未提交的事务要么补完要么作废”。新Leader选举出来后，会从所有节点中找出zxid最大的日志作为准绳，然后要求其他节点补齐缺失的事务。这也是为什么ZK能给自己挂上“强一致”标签的原因——对外承诺是：一旦写请求返回成功，这个数据就不会丢，而且后续任意一个客户端读，只要走同步读路径（sync read），都能读到这个值。不过要注意，ZK的普通读请求在线性一致性上是有妥协的，Kafka在实际使用中也主要依赖“写成功+Watcher通知”的组合，而不是依赖“读完一定最新”这个特性。

4. Kafka集群里的四类Zookeeper应用场景

理论铺垫完了，接下来进入本文的核心：Zookeeper在Kafka集群中到底出现在哪些环节。我会按实际启动Kafka集群时的顺序来，把每个场景的节点路径、事件时序、以及哪个组件在监听，都梳理清楚。

4.1 场景一：Broker注册和失效感知

每个Kafka Broker启动时，第一步就是向Zookeeper注册一个临时节点：

bash复制create /brokers/ids/{brokerId}

节点内容是一个JSON字符串，记录了这台Broker的地址、端口、JMX端口、机架信息等。同时，这个Broker还会在 /brokers/ids 上注册一个子节点变化监听，这样只要集群里其他Broker上线或下线，它都能收到Watcher通知。

依赖这个机制，整个集群不需要一个“中心注册表服务”，就能实时知道谁在线、谁下线了。Controller和普通Broker都会维护自己的元数据缓存，并在收到Watcher事件后刷新。

这里有个隐蔽的坑：Broker进程所在机器断电时，如果ZK的Session超时还没到，这个Broker在ZK看来仍然是“在线”的。如果此时客户端连接这个Broker，会发现连接中断，但ZK元数据里还留着它。只有Session超时时间一到，临时节点才会被自动清理，集群才会把它踢出去。这也是我在生产环境建议把zookeeper.session.timeout.ms调小的直接原因。

4.2 场景二：Controller选举

Kafka集群中有且只有一个Controller，它负责整个集群范围的管理操作：分区Leader选举、分区副本分配、Topic的创建和删除、元数据变更广播等。Controller不是通过配置文件指定的，而是靠ZK的一个临时节点来“抢”出来的。

bash复制create -e /controller {"version":1,"brokerid":1,"timestamp":...}

所有Broker启动时都会尝试创建这个临时节点，谁能创建成功，谁就是Controller。创建成功的Broker会把自己设为Controller，并开始接管集群管理任务；创建失败的Broker会注册一个Watcher，监听 /controller 节点是否消失。一旦当前Controller宕机、会话过期或主动退出，临时节点被删除，所有监听的Broker会同时收到通知，然后重新发起创建竞争。

这个场景充分体现了临时节点的价值：Controller不能自己说“我退了”，它的“退位”由ZK来判定。只要ZK检测到它的Session失效，/controller节点就被自动清理，集群马上进入新一轮选举。不需要等Controller进程恢复，也不需要人为干预。

不过这里对应了一个面试常考题：“2个Broker同时抢Controller会怎样？”答案是，ZK的写操作在ZAB协议下全局有序，最终只会有一个客户端创建成功，另一个创建时会收到“节点已存在”的异常，然后转为监听者。这就是ZK作为“分布式协调器”最典型的用法——用临时节点的唯一性实现互斥锁。

4.3 场景三：Topic元数据与分区Leader记录的持久化

Topic的元数据以持久节点的形式存在ZK里。最典型的是：

bash复制/brokers/topics/{topic}    持久节点，记录该Topic的分区数、副本因子、分区配置
/brokers/topics/{topic}/partitions/{partition}/state   持久节点，记录当前分区的Leader、ISR集合

我们平时创建Topic时，由Controller在该路径下写入分区配置；然后由Controller在内存里执行分区Leader分配，并把结果写入partition/state节点。普通Broker并不直接操作这些节点，它们都是通过Controller来感知变化的。

注意一个容易误解的点：分区Leader选举的决策者是Controller，ZK只负责把决策结果“存起来”并作为广播的元数据源。Controller在决定“谁是新Leader”时，依赖的是ISR集合和副本状态等数据，这些数据的来源之一就是ZK上的partition/state节点。所以我们可以说：ZK干的是存储和发现，Controller干的是决策和执行。

4.4 场景四：旧版本消费者组的偏移量存储

Kafka 0.8及更早版本，消费者组消费到的偏移量是直接存到Zookeeper上的，路径类似：

bash复制/consumers/{group}/offsets/{topic}/{partition}

但从Kafka 0.9开始，消费位移改存到Kafka自身的内部Topic __consumer_offsets里，由GroupCoordinator（某个Broker）负责管理。也就是说，ZK在消费者组这条链路里已经退出了，现在再说什么“消费者偏移量存在ZK里”，只适用于老得掉牙的版本。

这个演进的原因也很合理：位移提交属于高频写路径，如果每次消费提交都写ZK，一方面把ZK变成了一个高吞吐存储（不是它的设计目标），另一方面ZK的读写性能会成为消费者吞吐的瓶颈。Kafka把位移收敛到自身日志系统后，既可以利用副本同步保证位移不丢，又能跟随Kafka集群的扩展能力走。这也是“Zookeeper管控制面、Kafka管数据面”这句话在消费场景下的体现。

5. 用zkCli命令体检你的Kafka集群

讲了这么多机制，落点还是要能动手看。Zookeeper自带的命令行工具zkCli.sh（新版叫zkCli）是排查Kafka元数据问题最直接的入口。

bash复制./zkCli.sh -server zk1:2181,zk2:2181,zk3:2181

连上之后，先看根路径下有哪些子节点：

bash复制ls /

一个正常工作的Kafka集群，通常会有这些根节点：/brokers、/controller、/cluster、/controller_epoch、/isr_change_notification等。如果你只看到单独的/brokers、/controller，没有 /cluster 这种节点，可能是Kafka版本较老；在较新的版本里（如2.x），/cluster节点会用来记录集群ID。

继续往下看Broker注册情况：

bash复制ls /brokers/ids
get /brokers/ids/0

正常情况下，这个路径下应该有和集群Broker数量相等的子节点，节点名就是broker.id。get出来的内容包含host、port、jmx_port、rack等信息。

查看当前Controller是谁：

bash复制get /controller

返回结果里的brokerid字段就是当前Controller所在Broker。

查看Topic元数据：

bash复制ls /brokers/topics
get /brokers/topics/my-topic/partitions/0/state

下方会显示该分区当前Leader、Leader Epoch、ISR集合。如果ISR只有一个副本，而期望的副本因子是3，说明另外两个副本已经落后太多被踢出ISR了，需要去看那两个Broker的日志。

用这些命令做“体检”，基本能定位大多数“Kafka集群看起来正常但生产/消费异常”的问题。比如客户端报“metadata has no entry for topic”，首先去查 /brokers/topics 下面有没有这个Topic；如果查不到，就去查创建Topic时Controller日志有没有报错。

6. 从Zookeeper到KRaft：一场命中注定的“去ZK化”

最近半年经常看到用户在搜“docker kafka 安装不要 zookeeper”，这背后正是Kafka自身架构的一个大变化：KIP-500引入的KRaft模式，让Kafka可以完全脱离Zookeeper运行。

6.1 为什么Kafka要抛弃自己曾经的“大脑”

Zookeeper模式在实际生产环境里暴露了不少问题。

第一是运维复杂度高。Kafka集群本身已经是一套分布式系统，还要再维护一套高可用的ZK集群。而且ZK的部署方式、监控指标、故障处理逻辑和Kafka完全不一样，等于一个业务同时养两套基础架构团队。

第二是扩展瓶颈。当集群规模变大、Topic数量变成上万级时，ZK上的节点数量会指数增长。Controller每次做元数据变更都要写ZK，本身就是一次跨系统的网络IO；元数据越多，写延迟越高，最终会影响整个集群的感知和调度速度。

第三是逻辑割裂。Kafka的Controller一直在内存中维护完整的元数据缓存，ZK只是它的持久化后端。这种“内存权威+外部备份”的架构，在Controller故障切换时容易引发元数据不完整、缓存重建慢的问题。

KRaft模式把这些全部收编进Kafka自身：引入一个基于Raft协议的Quorum Controller，所有元数据（包括Broker注册、Topic配置、分区Leader和ISR记录）都落到独立的内部日志里，由Controller投票选主并复制给所有节点。从Kafka 3.3开始，KRaft已经被标记为可用于生产环境；当然，由于生态和工具链的成熟度、以及迁移成本，目前大量存量集群仍然停留在Zookeeper模式，新集群则越来越多直接上KRaft。

6.2 KRaft模式启动和部署上有什么区别

Zookeeper模式启动Kafka集群的步骤是：先配置并启动至少3个ZK节点，再配置每个Broker的zookeeper.connect，然后逐个启动Broker。KRaft模式完全不同：不需要再单独装ZK，只需要配置Kafka自己的controller.quorum.voters，用Kafka提供的存储格式化工具初始化元数据日志，然后分别以controller角色和broker角色启动节点。

两者对比更直观一点：

对于存量ZK模式集群的迁移，建议先在小环境做充分测试。KRaft的元数据日志机制和ZK模式差异很大，迁移工具虽然存在，但线上大规模切换仍需谨慎。我个人对大部分团队的建议是：如果只是维护存量集群，不要因为看到“新版本可以不用ZK”就立刻动手迁移；如果是新建集群、没有历史包袱，完全可以考虑直接上KRaft，一步到位。

7. 实战排错：为什么会出现“error while fetching metadata”

搜索关键词里有一个典型报错：docker kafka error while fetching metadata with correlation id。这个报错在Kafka客户端日志里非常常见，几乎每个用Docker起过Kafka的人都遇到过，而且很多初学者会误以为是Zookeeper的问题，然后去折腾ZK集群配置，结果毫无作用。

这个错误的直接原因是：客户端向某个Broker发起元数据请求（MetadataRequest）时，该Broker无法返回一个有效的、包含客户端需要访问Topic信息的响应。常见原因有三种：

第一，客户端配置的bootstrap.servers地址根本连不上Broker。这个最常见。在Docker环境中尤其典型：容器内部的Kafka绑定了内网IP，客户端在宿主机上用localhost去连，结果连不上；或者容器里的advertised.listeners配的还是容器ID，导致外部客户端拿到一个不可达地址，然后返回metadata错误。排查方法是先看Broker的server.properties里advertised.listeners有没有配置为宿主机可访问的地址。

第二，Topic不存在。当客户端向一个不存在的Topic发起发送或消费请求时，Kafka默认允许自动创建Topic（auto.create.topics.enable=true），但创建也需要Controller处理元数据变更，如果这个过程异常或者Topic真的创建失败，客户端会反复拿到“metadata has no entry for this topic”，表现就是error while fetching metadata。

第三，Controller处于异常状态。如果某个Broker作为当前Controller，但它自己已经长时间无法和ZK通信，ZK已经把它踢掉了，而其他Broker还没来得及接管Controller，此时客户端请求元数据就会超时或拿不到结果。这种情况要结合上一章的zkCli命令去查 /controller 当前是谁，然后去看这个Broker的日志。

所以遇到这个报错，如果你的第一步是怀疑Zookeeper，请先冷静。Zookeeper出问题会导致Controller无法选举、Broker无法注册，但“客户端拿不到元数据”这个现象，有80%概率是网络配置或Topic缺失导致的。真正要查的顺序，我觉得应该这么走：

1. 检查客户端到Broker的连通性：telnet {broker_ip} 9092，不通就先解决网络。
2. 检查Topic是否存在：用kafka-topics.sh --list 看一眼。
3. 检查Broker的advertised.listeners和listeners配置是否自洽。
4. 用zkCli.sh看 /brokers/ids 和 /controller 是否正常。
5. 看Broker侧日志里有没有关于metadata或controller的报错。

8. 生产环境里的Zookeeper调优和避坑清单

最后这些内容，是适合给正在维护生产集群的人看的。我不打算写长篇大论的参数表格，就把我实际踩过的、以及身边同行反馈过的几个高频问题列出来。

8.1 zookeeper.session.timeout.ms到底设多少

并且我在生产环境里见过太多次“Broker卡死但ZK半天才感知”的事故了。默认值6000ms（Kafka 2.x后的默认值）在大多数情况下偏慢，尤其当Kafka集群Pod被调度到新节点、内核OOM杀进程后，如果ZK需要很久才发现Broker挂了，这期间客户端连接会持续超时、Controller也会一直把请求发给这个“幽灵Broker”。

我个人的习惯是把这个值设在6000到10000ms之间，如果网络环境特别稳定，我会压到5到6秒。但前提是ZK集群本身得稳——如果你把ZK放到很差的磁盘或未做冗余的机器上，超时太短反而会导致ZK误判Broker假死，然后触发大量重平衡，那更麻烦。

8.2 ZK集群节点数为什么必须是奇数

前面在ZAB协议部分提过过半机制，这里再展开说一个实际教训：有人为了省钱，搭了2个ZK节点。2个节点在1个节点故障时剩下1个，永远凑不够过半（过半需要2），整个ZK集群直接不可用。所以2个节点的ZK集群，容错能力是0，还不如单节点——单节点至少没有过半问题。正确的做法是3节点起步，5节点更好。这也是为什么网上所有ZK集群教程都会要求“奇数节点”的原因：不是玄学，是过半机制直接导出的数学结论。

8.3 不要把ZK和Kafka Broker混部在同一批机器

混部看起来节省机器，实际隐患很大。Kafka Broker是磁盘IO大户，而ZK对磁盘同步刷盘延迟非常敏感。一旦Broker因为写入峰值把磁盘IO打满，ZK的fdatasync就会变慢，Leader与Follower之间的心跳可能超时，然后引发整个ZK集群的选举风暴。选举期间，所有依赖ZK的Kafka组件（Broker注册、Controller切换、元数据读）都会变慢，形成连锁故障。

如果条件有限只能混部，至少也要给ZK用独立的SSD、独立的CPU配额，并设置好IO优先级。但我的建议是能分开就分开，ZK集群的数据量其实很小，不需要大容量硬盘，给它几台低配但IO稳定的机器就够了。

8.4 监控ZK的哪些指标最容易发现问题

Zookeeper提供的四字命令是排查时最有用的工具：

bash复制echo stat | nc zk1 2181
echo mntr | nc zk1 2181

mntr命令会输出大量指标，我重点看这几个：

• zk_sync_processor_busy：同步处理器繁忙度，长期很高说明写压力大。
• zk_outstanding_requests：积压的未处理请求数，持续上升说明处理不过来。
• zk_followers：正常情况下，一个集群只有一个Leader，其余是Follower。如果这个数字反复跳，说明集群在频繁选举。
• zk_avg_latency：平均请求延迟，这个值突然变高通常和磁盘IO有关。

9. 面试答题框架和最后一组提醒

关于“Zookeeper在Kafka中的应用”这个主题，如果是面试场景，我建议按这个框架组织答案：

1. 先分层，把Kafka的一致性拆成控制面和数据面，明确Zookeeper管的是控制面。
2. 讲ZNode和Watcher如何支撑Broker注册与Controller选举。
3. 讲ZK自身通过ZAB协议保证“写请求全局有序、过半确认不丢数据”，这是Kafka放心把元数据交给它的信任基础。
4. 补充版本演进的视野：新版本KRaft已经可以不需要ZK，但存量集群迁移成本高，原理上KRaft用了类似Raft的日志机制来替代ZK。
5. 如果你是面试官，听到一个候选人在答这道题时能主动提到HW/LEO、ISR和Epoch这些概念，说明他真的理解Kafka，而不只是背了题。

结尾聊点个人实际体会。我刚维护Kafka集群那几年，最大的感受是：Zookeeper在Kafka里的角色，用一句大白话说就是“一个挂了会影响很多事，但平时你感觉不到它存在”的基础设施。很多线上问题表面上像ZK的锅，实际到最后发现都是配置、网络、或者对机制理解不到位造成的。后来我养成了一个习惯，遇到Kafka集群异常，先别急着重启或调参，先用zkCli把 /brokers/ids、/controller、partition/state这几个节点读一遍，往往几分钟就能定位出到底是谁的状态不对。这套“先看元数据、再查日志、最后动参数”的排查顺序，帮我省下了大量时间。

如果你正在学习Kafka，也不用被这一堆机制吓到。把本文这张四层一致性对照表吃透，再亲手用zkCli去现网Kafka上点一遍那些路径，你对Zookeeper在Kafka里的作用就算真正入门了。至于KRaft全面替代ZK的那一天，也不是说这套知识就没用了——分布式系统里“选主、元数据共识、故障感知”这几个问题永远存在，换的只是实现方式，底层逻辑从来没有变过。