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的分区和副本信息。文章来源:https://www.toymoban.com/news/detail-503516.html
这种机制确保了在broker关闭和重新启动的情况下,集群的分区和副本分配保持一致,从而实现高可用性和容错性。但需要注意的是,如果一个broker被关闭后,一段时间内没有使用相同的ID启动新的broker,那么其他broker可能会将该ID标记为失效,并重新分配其上的分区和副本。文章来源地址https://www.toymoban.com/news/detail-503516.html
到了这里,关于Kafka系列 - kafka中Zookeeper的作用是什么?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!