分布式 - 消息队列Kafka：Kafka中Zookeeper的作用是什么？

01. 如何查看kafka 元数据存储目录？

以 kafka 伪集群来看下 Zookeeper 中存储的 Kafka 信息。在配置 kafka 伪集群时，在kafka 配置文件 server.properties 中配置了连接 zookeeper 集群的地址：

zookeeper.connect=localhost:2182,localhost:2183,localhost:2184

Kafka的元数据存储在Zookeeper中，而不是本地文件系统中。因此，要查看Kafka的元数据存储目录，您需要连接到Zookeeper并查看其中的数据。

① 方式1：打开Zookeeper客户端并连接到Zookeeper服务器，进入Zookeeper 安装目录的bin文件夹，执行Zookeeper客户端命令

[root@localhost bin]# ./zkCli.sh -server 10.60.215.238:2184
Connecting to 10.60.215.238:2184
2023-05-30 17:33:20,391 [myid:] - INFO  [main:Environment@100] - Client environment:zookeeper.version=3.4.14-4c25d480e66aadd371de8bd2fd8da255ac140bcf, built on 03/06/2019 16:18 GMT
2023-05-30 17:33:20,394 [myid:] - INFO  [main:Environment@100] - Client environment:host.name=localhost
2023-05-30 17:33:20,394 [myid:] - INFO  [main:Environment@100] - Client environment:java.version=11.0.19
2023-05-30 17:33:20,395 [myid:] - INFO  [main:Environment@100] - Client environment:java.vendor=Oracle Corporation
2023-05-30 17:33:20,395 [myid:] - INFO  [main:Environment@100] - Client environment:java.home=/opt/soft/java/jdk-11.0.19
2023-05-30 17:33:20,395 [myid:] - INFO  [main:Environment@100] - Client environment:java.class.path=/opt/soft/zookeeper/zookeeper-03/bin/../zookeeper-server/target/classes:/opt/soft/zookeeper/zookeeper-03/bin/../build/classes:/opt/soft/zookeeper/zookeeper-03/bin/../zookeeper-server/target/lib/*.jar:/opt/soft/zookeeper/zookeeper-03/bin/../build/lib/*.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/slf4j-log4j12-1.7.25.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/slf4j-api-1.7.25.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/netty-3.10.6.Final.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/log4j-1.2.17.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/jline-0.9.94.jar:/opt/soft/zookeeper/zookeeper-03/bin/../lib/audience-annotations-0.5.0.jar:/opt/soft/zookeeper/zookeeper-03/bin/../zookeeper-3.4.14.jar:/opt/soft/zookeeper/zookeeper-03/bin/../zookeeper-server/src/main/resources/lib/*.jar:/opt/soft/zookeeper/zookeeper-03/bin/../conf:
2023-05-30 17:33:20,395 [myid:] - INFO  [main:Environment@100] - Client environment:java.library.path=/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
2023-05-30 17:33:20,395 [myid:] - INFO  [main:Environment@100] - Client environment:java.io.tmpdir=/tmp
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:java.compiler=<NA>
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:os.name=Linux
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:os.arch=amd64
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:os.version=4.18.0-193.el8.x86_64
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:user.name=root
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:user.home=/root
2023-05-30 17:33:20,396 [myid:] - INFO  [main:Environment@100] - Client environment:user.dir=/opt/soft/zookeeper/zookeeper-03/bin
2023-05-30 17:33:20,397 [myid:] - INFO  [main:ZooKeeper@442] - Initiating client connection, connectString=10.60.215.238:2184 sessionTimeout=30000 watcher=org.apache.zookeeper.ZooKeeperMain$MyWatcher@2e3fc542
Welcome to ZooKeeper!
JLine support is enabled
[zk: 10.60.215.238:2184(CONNECTING) 0] 2023-05-30 17:33:20,645 [myid:] - INFO  [main-SendThread(10.60.215.238:2184):ClientCnxn$SendThread@1025] - Opening socket connection to server 10.60.215.238/10.60.215.238:2184. Will not attempt to authenticate using SASL (unknown error)
2023-05-30 17:33:20,653 [myid:] - INFO  [main-SendThread(10.60.215.238:2184):ClientCnxn$SendThread@879] - Socket connection established to 10.60.215.238/10.60.215.238:2184, initiating session
2023-05-30 17:33:20,664 [myid:] - INFO  [main-SendThread(10.60.215.238:2184):ClientCnxn$SendThread@1299] - Session establishment complete on server 10.60.215.238/10.60.215.238:2184, sessionid = 0x2004e1182c20000, negotiated timeout = 30000

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
ls /
[cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, log_dir_event_notification, latest_producer_id_block, config]
[zk: 10.60.215.238:2184(CONNECTED) 1]

② 方式2：进入 Kafka 安装目录的 bin/ 文件夹，执行以下命令连接到 ZooKeeper：

[root@localhost bin]# ./zookeeper-shell.sh 10.60.215.238:2184
Connecting to 10.60.215.238:2184
Welcome to ZooKeeper!
JLine support is disabled

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
ls /
[cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, log_dir_event_notification, latest_producer_id_block, config]

③ 查看 zookeeper 中存储的 kafka 元数据信息：

ls /
[cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, log_dir_event_notification, latest_producer_id_block, config]

Kafka的元数据存储在Zookeeper中，而不是本地文件系统中。Zookeeper是一个分布式的协调服务，用于存储Kafka集群的元数据，包括主题、分区、消费者组等信息。Kafka通过Zookeeper来管理集群中的Broker、Topic和Consumer等信息，以及进行Leader选举、Partition分配等操作。因此，Kafka的元数据存储目录实际上是Zookeeper的数据节点。在Kafka的配置文件中，可以通过配置zookeeper.connect参数来指定Zookeeper的连接地址。

在Zookeeper中，Kafka的元数据存储在/brokers、/controller和/config三个目录下。其中，/brokers目录存储了Kafka集群中所有Broker的信息，包括它们的ID、主机名、端口号等；/controller目录存储了当前的Controller Broker的ID，Controller Broker是Kafka集群中负责管理分区副本分配和故障转移的Broker；/config目录存储了Kafka集群的配置信息。

这些元数据信息都是由Kafka控制器节点维护的，而不是由Broker节点维护的。因此，如果控制器节点宕机或者出现故障，Kafka集群的元数据信息可能会受到影响。

需要注意的是，Kafka的元数据存储在Zookeeper中是为了支持集群的动态扩容和缩容。因此，如果你需要修改Kafka的配置信息，应该通过修改Zookeeper中的配置来实现。

02. kafka 元数据存储目录 /controller

/controller目录: 这个目录存储了当前Kafka集群的控制器节点的ID。每个Kafka集群只有一个控制器节点，该节点负责管理集群的元数据信息和分区分配。

get /controller
{"version":1,"brokerid":0,"timestamp":"1685072164216"}
cZxid = 0x200000116
ctime = Fri May 26 11:36:04 CST 2023
mZxid = 0x200000116
mtime = Fri May 26 11:36:04 CST 2023
pZxid = 0x200000116
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x4e11419a000e
dataLength = 54
numChildren = 0

可以看到该 kafka 集群的控制器节点的 brokerid 为0

03. kafka 元数据存储目录 /brokers

① /brokers目录: 存储Kafka集群中所有broker的信息，每个节点都有一个唯一的ID和一个地址列表，包括它们的ID、主机名、端口号等。

ls /brokers
[ids, topics, seqid]

② /brokers/ids: 这个目录存储了Kafka集群中所有Broker节点的ID。每个Broker节点都有一个唯一的ID，该ID由Kafka控制器分配。

ls /brokers/ids
[0, 1, 2]

获取kafka节点详情信息：

get /brokers/ids/0
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://10.60.215.238:9092"],"jmx_port":-1,"host":"10.60.215.238","timestamp":"1685072066057","port":9092,"version":4}
cZxid = 0x2000000ef
ctime = Fri May 26 11:34:26 CST 2023
mZxid = 0x2000000ef
mtime = Fri May 26 11:34:26 CST 2023
pZxid = 0x2000000ef
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x4e11419a000e
dataLength = 196
numChildren = 0

根据查询结果，该 broker 的 ID 为 0，监听地址为 PLAINTEXT://10.60.215.238:9092

③ /brokers/topics: 这个目录存储了Kafka集群中所有Topic的元数据信息，包括每个Topic的名称、分区数、副本数等。

ls  /brokers/topics
[test, __consumer_offsets]

ls /brokers/topics/test
[partitions]
ls /brokers/topics/test/partitions
[0, 1, 2]
ls /brokers/topics/test/partitions/0
[state]
get /brokers/topics/test/partitions/0/state
{"controller_epoch":7,"leader":2,"version":1,"leader_epoch":3,"isr":[0,2]}
cZxid = 0x2000000da
ctime = Fri May 26 11:32:19 CST 2023
mZxid = 0x20000012f
mtime = Fri May 26 11:41:09 CST 2023
pZxid = 0x2000000da
cversion = 0
dataVersion = 5
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 74
numChildren = 0
get /brokers/topics/test/partitions/1/state
{"controller_epoch":5,"leader":0,"version":1,"leader_epoch":2,"isr":[0,1]}
cZxid = 0x2000000d9
ctime = Fri May 26 11:32:19 CST 2023
mZxid = 0x20000010e
mtime = Fri May 26 11:35:58 CST 2023
pZxid = 0x2000000d9
cversion = 0
dataVersion = 4
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 74
numChildren = 0
get /brokers/topics/test/partitions/2/state
{"controller_epoch":6,"leader":1,"version":1,"leader_epoch":2,"isr":[1,2]}
cZxid = 0x2000000d8
ctime = Fri May 26 11:32:19 CST 2023
mZxid = 0x20000012a
mtime = Fri May 26 11:36:10 CST 2023
pZxid = 0x2000000d8
cversion = 0
dataVersion = 4
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 74
numChildren = 0

• controller_epoch: 控制器的代数，用于检测控制器故障转移。
• leader: 当前领导者的ID。在这个响应中，领导者的ID是0，表示该分区当前由第0个broker担任领导者。
• version: 分区状态的版本号。
• leader_epoch: 领导者的代数，用于检测领导者故障转移。
• isr: 可用于服务读取请求的副本集合，即“in-sync replicas”。在这个响应中，ISR包含两个broker的ID：0和1，表示这两个broker上的副本与领导者的副本保持同步。

04. kafka 元数据存储目录 /config

/config目录: 存储Kafka集群的配置信息，包括broker的默认配置、topic的默认配置等。

ls /config
[changes, clients, brokers, topics, users]

05. kafka 元数据存储目录 /admin

Kafka元数据存储目录/admin主要用于存储管理员接口操作的相关信息，包括以下内容：

① Topic删除事件：当管理员删除一个Topic时，相关的元数据信息将被存储在/admin/delete_topics目录下。

② 分区迁移事件：当管理员执行分区迁移操作时，相关的元数据信息将被存储在/admin/reassign_partitions目录下。

③ 优先副本选举：当管理员执行优先副本选举操作时，相关的元数据信息将被存储在/admin/preferred_replica_election目录下。

④ 信息：一般为临时节点，用于存储一些临时的元数据信息，例如正在进行的分区重分配操作的状态信息等。

这些元数据信息对于Kafka集群的管理和维护非常重要，管理员可以通过访问/admin目录下的子目录来查看和管理这些信息。

/admin/delete_topics: 这个目录存储了待删除的Topic列表。当Kafka控制器接收到删除Topic的请求时，它会将该Topic的名称添加到这个目录中，然后通知所有Broker节点删除该Topic。

ls /admin/delete_topics
[]

06. kafka 元数据存储目录 /consumers

存放消费者相关信息 (一般为空)：0.9版本之前用于存Offset信息，0.9版本之后Offset信息存在在kafka 主题中

ls /consumers
[]

07. Kafka中Zookeeper起什么作用，可以不用Zookeeper么？

在Kafka中，Zookeeper扮演着多个重要角色：

① 配置管理：Kafka集群的配置信息、主题和分区的元数据都存储在Zookeeper中。

② Broker注册：Kafka Broker启动时会向Zookeeper注册自己的信息，包括Broker的ID、主机名、端口等。

③ Leader选举：Kafka的分区副本机制中，每个分区都有一个Leader负责读写请求的处理。当Leader宕机时，Zookeeper会协助进行新的Leader选举。

④ 消费者组管理：Kafka的消费者组机制中，Zookeeper会记录消费者组的信息，包括消费者组的成员、消费进度等。

因此，Zookeeper在Kafka中扮演着非常重要的角色，如果不使用Zookeeper，Kafka将无法正常工作。

08. Kafka 和 ZooKeeper 之间的关系是什么？

Kafka 使用 ZooKeeper 来管理和协调 Kafka 集群中的各个节点。ZooKeeper 负责维护 Kafka 集群的元数据，例如主题、分区、消费者组等信息，并协调 Kafka 集群中的各个节点之间的通信。

09. Kafka 中的分区是如何管理的？

Kafka 中的分区是由 ZooKeeper 来管理的。ZooKeeper 维护了每个分区的元数据，包括分区的 ID、副本的位置、领导者等信息。Kafka 的生产者和消费者通过 ZooKeeper 来获取分区的元数据，并与分区的领导者进行通信。

10. kafka的工作需要Zookeeper的配合，它是如何配合的？

Kafka和Zookeeper是两个独立的开源项目，但是在Kafka的工作中，Zookeeper是必不可少的。下面是Kafka和Zookeeper之间的配合工作：

① Kafka使用Zookeeper来存储集群的元数据，包括主题（topic）、分区（partition）和消费者组（consumer group）等信息。这些元数据的存储和管理是由Zookeeper来完成的。

② 当Kafka集群中的Broker启动或关闭时，它们会向Zookeeper注册或注销自己的信息。这样，Kafka集群中的所有Broker都可以通过Zookeeper了解到其他Broker的状态。

③ 当Kafka集群中的某个分区的Leader节点发生变化时，Zookeeper会通知所有的Broker，以便它们可以更新自己的元数据信息。

④ 当消费者组中的消费者启动或关闭时，它们也会向Zookeeper注册或注销自己的信息。这样，Kafka集群中的所有Broker都可以通过Zookeeper了解到消费者组中的消费者的状态。

⑤ 当消费者组中的消费者需要消费某个分区的消息时，它们会向Zookeeper请求该分区的元数据信息。Zookeeper会返回该分区的Leader节点的信息，以便消费者可以向该节点发送拉取请求。

总之，Kafka和Zookeeper之间的配合工作是非常紧密的，Zookeeper在Kafka集群中扮演着非常重要的角色，它负责存储和管理集群的元数据信息，以及协调Kafka集群中各个节点之间的通信。

11. Kafka是怎么跟Zookeeper进行交互的？

Kafka是一个分布式的消息系统，而Zookeeper是一个分布式的协调服务。在Kafka中，Zookeeper主要用于管理Kafka集群的元数据，包括Kafka的broker信息、topic和partition的信息等。Kafka通过与Zookeeper进行交互来实现以下功能：

① Broker注册：当一个Kafka broker启动时，它会向Zookeeper注册自己的信息，包括broker的ID、主机名和端口号等。

② Topic和Partition的管理：Kafka的topic和partition信息存储在Zookeeper的节点上，Kafka通过与Zookeeper进行交互来创建、删除、修改topic和partition的信息。

③ Leader选举：Kafka的每个partition都有一个leader broker，当leader broker宕机时，Kafka需要从剩余的broker中选举一个新的leader。这个过程需要通过与Zookeeper进行交互来实现。

④ Consumer Group的管理：Kafka的consumer group信息也存储在Zookeeper的节点上，Kafka通过与Zookeeper进行交互来创建、删除、修改consumer group的信息。

总之，Kafka通过与Zookeeper进行交互来实现集群的元数据管理和协调，保证了Kafka集群的高可用性和可靠性

12. kafka 依赖于ZooKeeper存在什么问题？

Kafka 依赖于 ZooKeeper 主要是为了实现分布式协调和管理。具体来说，ZooKeeper 负责管理 Kafka 集群的元数据，如 broker 的状态、topic 和 partition 的信息等。同时，ZooKeeper 还可以用于实现 Kafka 的 leader 选举和消费者组的协调等功能。然而，Kafka 依赖于 ZooKeeper 也存在一些问题：

① 单点故障：ZooKeeper 是一个集中式的服务，如果 ZooKeeper 发生故障，整个 Kafka 集群都将受到影响。

② 性能瓶颈：ZooKeeper 的性能瓶颈可能会影响 Kafka 的性能。例如，ZooKeeper 的写入操作可能会成为瓶颈，从而影响 Kafka 的生产和消费速度。

③ 部署和维护成本高：ZooKeeper 的部署和维护需要一定的成本，需要专门的人员进行管理和维护。

13. kafka新版本为什么不再依赖于Zookeeper？

Kafka2.8.0版本于(2021年4月19日)发布，该版本提供了KIP-500的早期访问版本，它允许在没有zookeeper的情况下运行Kafka集群，而取代zookeeper的是Kafka内部实现的KRaft协议。这种新体系结构使每个集群支持更多分区、更简单的操作和更严格的安全性。需要特别强调的一点是；当前版本还不完善，不能用于生产环境。

Kafka 2.8版本引入了KIP-500，这是一个重大的变化，它将Kafka的元数据存储从Zookeeper迁移到了内部的Kafka集群中。在此之前，Kafka使用Zookeeper来存储集群的元数据，包括主题、分区、消费者组等信息。但是，随着Kafka集群规模的增大，Zookeeper的性能和可靠性成为了瓶颈，因此Kafka社区决定将元数据存储迁移到Kafka集群中。

这样做的好处是，Kafka集群可以更好地控制自己的元数据，而不需要依赖外部的Zookeeper。这样可以提高Kafka的可靠性和性能，并且简化了Kafka的部署和维护。

14. Kafka 如何维护集群的成员关系？

① Kafka使用ZooKeeper来维护集群的成员信息，确保集群中的每个broker都能够知道其他broker的存在。每个broker都有一个唯一的标识符，可以在配置文件中指定，也可以自动生成。当broker启动时，它会创建一个临时节点，并将自己的ID注册到ZooKeeper中。这个临时节点的路径是 /brokers/ids/<broker_id>，其中<broker_id>是broker的唯一标识符。

除了broker之外，控制器和其他一些生态系统工具也会订阅ZooKeeper的 /brokers/ids 路径，以便在有broker加入或退出集群时收到通知。当有新的broker加入集群时，它会创建一个新的临时节点，并将自己的ID注册到ZooKeeper中。当有broker退出集群时，它的临时节点会被删除，其他broker会收到通知。

通过ZooKeeper，Kafka能够动态地管理集群成员，确保集群中的每个broker都能够知道其他broker的存在，并及时地响应加入或退出集群的事件。这种机制使得Kafka集群更加健壮和可靠。

② 如果你试图启动另一个具有相同ID的broker，则会收到一个错误——新broker会尝试进行注册，但不会成功，因为ZooKeeper中已经有一个相同的节点。

③ 当broker与ZooKeeper断开连接（通常会在关闭broker时发生，但在发生网络分区或长时间垃圾回收停顿时也会发生）时，它在启动时创建的临时节点会自动从ZooKeeper上移除。监听broker节点路径的Kafka组件会被告知这个broker已被移除。

broker对应的ZooKeeper节点会在broker被关闭之后消失，但它的ID会继续存在于其他数据结构中。例如，每个主题的副本集中就可能包含这个ID。在完全关闭一个broker后，如果使用相同的ID启动另一个全新的broker，则它会立即加入集群，并获得与之前相同的分区和主题。这是因为Kafka使用ZooKeeper来管理集群的元数据，包括分区和副本的分配情况。当一个新的broker使用相同的ID启动时，它会向ZooKeeper注册自己，并获取之前分配给该ID的分区和副本信息。

这种机制确保了在broker关闭和重新启动的情况下，集群的分区和副本分配保持一致，从而实现高可用性和容错性。但需要注意的是，如果一个broker被关闭后，一段时间内没有使用相同的ID启动新的broker，那么其他broker可能会将该ID标记为失效，并重新分配其上的分区和副本。