zookeeper和Kafka的关系

生命不息战斗不止！！！

已于 2024-03-13 14:04:49 修改

阅读量9.4k

点赞数 5

分类专栏：大数据文章标签： java

于 2021-08-21 16:25:02 首次发布

无

本文链接：https://blog.csdn.net/wwwwwww31311/article/details/119840991

版权

大数据专栏收录该内容

2 篇文章 1 订阅

订阅专栏

zookeeper介绍

zk的数据结构

zk类似于linux文件系统的树结构，树的基本组成单位是一个个Znode结点，每一个节点可以通过路径来标识，每个znode都由value值和next指针构成，如果znode的value值为空，那么该节点只相当于一个目录，Znode分为两种类型

临时节点(Ephemeral)：当客户端和服务端断开连接后，所创建的Znode(节点)会自动删除
持久节点(Persistent)：当客户端和服务端断开连接后，所创建的Znode(节点)不会删除

查看zk树结构的命令是ls，查看zk节点值的命令是get

zk监听器

监听Znode节点的数据变化
监听子节点的增减变化

zk的应用

zk的底层实现主要就是依靠监听器+ zk的数据结构，可以应用于以下几点

基于zookeeper实现统一配置管理
统一命名服务
分布式锁
集群状态感知

临时节点与持久节点

Node 可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个 ZNode 被创建了，除非主动进行 ZNode 的移除操作，否则这个 ZNode 将一直保存在 ZooKeeper 上。而临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

事件监听器

Watcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。

zk分布式架构

ZooKeeper 采用的是主从模式，有主节点和从节点。从设计模式的角度，它是一个基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper 就将负责通知已经注册的那些观察者做出相应的反应。

zk架构中的角色

ZooKeeper 中的角色包括 Leader、Follower、Observer。Leader 是集群主节点，主要负责管理集群状态和接收用户的写请求；Follower 是从节点，主要负责集群选举投票和接收用户的读请求；Observer 的功能与 Follower 类似，只是没有投票权，主要用于分担 Follower 的读请求，降低集群的负载。

zk在kafka中的体现

kafka leader选举

Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，kafk集群中的所有服务会以共同注册zk中的/controller来竞争kafka的leader角色，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在zk的/controller目录上注册临时节点的这个Kafka Broker会被选举为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。也就是为/Controller节点在ZooKeeper注册Watch。

zk中监听器对kafka的作用(记录ISR)

zk的监听器会监听其他的Kafka Broker的所有信息，一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。

zk中临时节点对kafka的意义

每个Broker服务器在启动时，都会到Zookeeper上进行注册，即创建/brokers/ids/[0-N]的节点，然后写入IP，端口等信息，Broker创建的是临时节点，所以一旦Broker下线，对应Broker节点也就被删除了，因此我们可以通过zookeeper上Broker节点的变化来动态表征Broker服务器的可用性,Kafka的Topic也类似于这种方式。

kafka和zookeeper的整体架构

在Kafka的设计中，选择了使用Zookeeper来进行所有Broker的管理，kafka配置文件中有关kafka和zookeeper的配置如下，意思是每个broker上的本地zookeeper都会注册整个kafka集群的服务信息

zookeeper.connect=localhost:2181

kafka在zk上的配置总览

/brokers/ids专门用来进行kafka集群服务器列表记录的点；
/brokers/topics专门用来记录kafka集群服务器中的全部topic；
   /brokers/topics/{topicName}：记录名为xxx的topic
        /brokers/topics/topic-n/partitions：记录每个topic下的全部分区信息，包括一个【offse】
             /brokers/topics/topic-n/partitions/{partitionNo}：0代表0号分区，1代表1号分区，以此类推
                  /brokers/topics/topic-n/partitions/{partitionNo}/state:存储中央控制器controller选取次数、leader partition所在broker的id，leader选举此时，初始时0，isr信息

/controller:kafka 存储服务器集群注册到zookeeper时成为controller的broker这个节点信息
/controller_epcho:kafka 存储服务器集群注册到zookeeper时成为controller的broker这个节点信息

在这里插入图片描述

注意点

0.9之前offset存储在zk下，也就是consumer相关的信息存在zk下的/consumers目录下了，但是0.9版本后consumer的信息存储在了brokers上的一块内存中了 /brokers/topics/__consumer_offsets/下存储，其中offset时以topic的分区为单位进行存储的

/brokers/ids目录下生成的节点是临时结点，存储的是kafka服务的连接信息
/brolers/topics下存储kafka的topic信息，是永久性节点，例如创建了name为test的topic

kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

消费者生产者负载均衡

生产者需要将消息合理的发送到分布式Broker上，这就面临如何进行生产者负载均衡问题。对于生产者的负载均衡，Kafka支持传统的4层负载均衡，zookeeper同时也支持zookeeper方式来实现负载均衡。

根据生产者的IP地址和端口来为其定一个相关联的Broker,通常一个生产者只会对应单个Broker,只需要维护单个TCP链接。这样的方案有很多弊端，因为在系统实际运行过程中，每个生产者生成的消息量，以及每个Broker的消息存储量都不一样，那么会导致不同的Broker接收到的消息量非常不均匀，而且生产者也无法感知Broker的新增与删除。
使用zookeeper进行负载均衡
很简单，生产者通过监听zookeeper上Broker节点感知Broker，Topic的状态，变更，来实现动态负载均衡机制，当然这个机制Kafka已经结合zookeeper实现了。

kafka日志数据分离操作

原因：kafka中的数据存储配置字段为logs.dir,容易让人误解为日志，事实上kafka的日志和数据都是存在/kafka/logs下的，需要手动进行分离，但并非一定要分离，看个人爱好

删除kafka集群下kafka/logs文件夹
删除zk集群下的zookeeper/zkData中的version文件

数据分离后创建一个分区数何副本数都为2的topic first，那么/kafka-data下会生成first-0和first-1两份数据文件分别代表first两个分区的文件，另外的两个副本分别在其它位置，这里起到了数据库的作用，在一段时间内存储数据 => 主题是逻辑上的，分区时物理上的

kafka的每个分区数据如果不加以控制就会无限堆积，所以kafka的分区存在分片机制即每超过1g就进行分片segement，每个分片单独具有一个log和一个index,log是实实在在存储数据的，index可以看着是log的索引

在这里插入图片描述
00000000000000170410.log这个文件记录了第170411到~（下一个log文件编号）的消息。
00000000000000170410.index：假设这个消息中有N条消息，第3条消息在index文件中对应的是348，也就是说在log文件中，第3条消息的偏移量为348。

zk作用小结

zk 为 Kafka 提供了元数据的管理，例如一些 Broker 的信息、主题数据、分区数据等等
zk辅助kafka中leader选举，

kafka新版本

生命不息战斗不止！！！

关注

5
点赞
踩
21

收藏

觉得还不错? 一键收藏
0
评论
zookeeper和Kafka的关系

1.在Kafka的设计中，选择了使用Zookeeper来进行所有Broker的管理，体现在zookeeper上会有一个专门用来进行Broker服务器列表记录的点，节点路径为/brokers/ids每个Broker服务器在启动时，都会到Zookeeper上进行注册，即创建/brokers/ids/[0-N]的节点，然后写入IP，端口等信息，Broker创建的是临时节点，所有一旦Broker上线或者下线，对应Broker节点也就被删除了，因此我们可以通过zookeeper上Broker节点的变化来动态表征B
复制链接

扫一扫