在前面kafka的集群搭建中,我们在启动kafka之前,需要先启动Zookeeper,为什么要Zookeeper呢?以及Zookeeper在Kafka集群中做什么用?

Zookeeper 是 Kafka 的分布式协调工具，负责管理 Kafka 集群的元数据、Leader 选举等功能。

Zookeeper 的核心功能:

   1. 集群元数据管理：Zookeeper 保存了 Kafka 集群的元数据，例如 Broker 信息、Topic 信息、Partition 信息等
   2. Leader 选举：Zookeeper 负责选举 Kafka 中的 Leader，确保 Kafka 集群的高可用性。
   3. 同步机制：Zookeeper 作为 Kafka 的协调者，确保了分布式系统中的一致性。

Kafka 中的 Zookeeper 主要用于以下场景：

• Broker 注册与发现：Kafka Broker 启动时会向 Zookeeper 注册，Zookeeper 负责 Broker 的发现和管理。
• Partition Leader 选举：当某个 Broker 宕机时，Zookeeper 负责重新选举 Partition 的 Leader，保证 Kafka 集群的可用性。

1 Broker注册

当Kafka Broker启动时,就会向Zookeeper注册, Zookeeper就会保存Kafka 集群的元数据.而ZooKeeper 的核心概念是 ZNode，它类似于文件系统中的目录和文件，用于存储和管理数据。ZNode 可以被创建、读取、更新和删除等操作. 所以当Kafka Broker第一次启动的时候, 会在Zookeeper中创建多个ZNode节点(本质就是一个目录),并把自己的信息保存到Zookeeper的ZNode节点. 我们可以使用一个Zookeeper工具(prettyZoo)来查看Zookeeper的存储的Broker信息.

先从GitHub下载prettyZoo工具,网址: https://github.com/vran-dev/PrettyZoo/releases

如果是安装版,点击安装包,下一步下一步就ok, 如果是免安装版,解压就可以使用

运行prettyZoo, 在开始界面输入Zookeeper的ip以及端口,就可以连接Zookeeper了

点击刚刚创建的连接,进行连接

再启动kafka,此时我们就能看到kafka保存在Zookeeper相关信息

下图介绍了Zookeeper保存Broker信息的目录

在zookeeper的服务端存储的Kafka相关信息：

• /kafka/brokers/ids： [0,1,2] 记录有哪些服务器
• /kafka/brokers/topics/first/partitions/0/state：{"leader":1 ,"isr":[1,0,2] } 记录每个主题下的分区谁是Leader，有哪些服务器可用
• /kafka/controller：{"brokerid" :0} 辅助选举Leader的Broker

Zookeeper存储结构如下图

Kafka Broker 总体工作流程:

1.Broker启动后,会在zookeeper的/brokers/ids路径下注册

2.同时，其中一个broker会被选举为控制器（Kafka Controller）。选举规则也很简单，谁先注册到zookeeper中的/controller节点，谁就是控制器。Controller主要负责管理整个集群中所有分区和副本的状态。

3.成功在zk中注册的controller的Broker会监听brokers节点的变化

4.Kafka Controller会进行Leader选择，比如下图中针对TopicA中的1号分区，选择broker1作为Leader, 然后会将选择的节点信息注册到zookeeper的/brokers/topics路径下，记录谁是Leader，有哪些服务器可用。

5.controller将节点的信息上传到zk

6.其他Broker从zk同步相关信息（如果某一个controller宕机，随时成为leader）

7.生产者发送信息, 只会把数据发往Leader

8.其他follower主动同步Leader相关信息（底层采用log方式存储）

9.broker应答消息,被选举为Leader的topic分区提供对外的读写服务

10.如果broker1的leader宕机，controller监听到了节点的变化，从zk中重新获取获取isr，重新选举出新的leader

11.更新zk中的Leader及isr

2 副本选举

Kafka集群中有一个broker的Controller会被选举为Controller Leader，负责管理集群broker的上下线，所有topic的分区副本分配和Leader选举等工作。

当 Leader 副本发生故障时，Kafka 集群会从 ISR 中选择一个副本作为新的 Leader 副本，以保证分区的可用性。

这个过程是自动进行的，由 Kafka 控制器（Controller）负责执行。

下面是副本选举的步骤：

（1）leader副本失效检测： Kafka 集群中的每个节点都会监视分区的leader副本的状态。如果leader副本失效，即无法响应请求或已经停止工作，节点会检测到这一情况。

（2）副本选择：

在leader副本失效后，控制器会从 ISR（同步副本集合）中选择一个副本作为新的领导者。ISR 中的副本是与leader保持同步状态的副本，它们的数据与领导者的数据是一致的。 通常情况下，新的领导者会从 ISR 中选择。这是因为 ISR 中的副本与领导者保持同步，可以更快地接管领导者的角色，而不需要进行数据同步。

选举规则:在ISR（与 Leader 副本保持同步的 Followers 副本集合）中存活为前提，按照AR（Assigned Repllicas）中排在前面的优先。例如ar[1,0,2],isr[1，0，2，那么leader就会按照1，0，2的顺序轮询。而AR中的这个顺序kafka会进行打散，分摊kafka broker的压力。

ISR（In-Sync Replicas）: 表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认 30s。直到其追赶上 Leader 副本的进度。才加入到ISR,Leader 发生故障之后，就会从 ISR 中选举新的Leader。

AR（Assigned Repllicas）: AR = ISR + OSR

OSR: 表示Follower与Leader副本同步时，延迟过多的副本

（3）副本选举通知：

一旦控制器选择了新的leader副本，它会将这一信息通知给集群中的所有节点。 （4）选举结果确认：

所有节点接收到leader的选举通知后，它们会更新本地的分区信息，将新的leader副本标记为领导者，并更新其角色状态。 （5）客户端重定向：

一旦新的领导者选举完成，Kafka 控制器会将分区的元数据更新到 Zookeeper（或者最新版本的 Kafka 使用自己的元数据存储），并通知客户端有关领导者副本的更改。客户端在收到更新后，会将请求重定向到新的leader副本，确保数据的连续性和可用性。

但是如果当运行中的控制器突然宕机或意外终止时，Kafka 通过监听zookeeper能够快速地感知到，并立即启用备用控制器来代替之前失败的控制器。这个过程就被称为 Failover，该过程是自动完成的，无需你手动干预。

开始的时候，Broker 0 是控制器。当 Broker 0 宕机后，ZooKeeper 通过`` Watch 机制感知到并删除了 /controller 临时节点。之后，所有存活的 Broker 开始竞选新的控制器身份。Broker 3最终赢得了选举，成功地在 ZooKeeper 上重建了 /controller 节点。之后，Broker 3 会从 ZooKeeper 中读取集群元数据信息，并初始化到自己的缓存中，后面就有Broker 3来接管选择Leader的功能了。

Tags：zookeeper客户端工具