kafkazookeeper（kafkazookeeper迁移）

本篇文章给大家谈谈kafkazookeeper，以及kafkazookeeper迁移对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Zookeeper 在 Kafka 中的作用
• 2、为什么Kafka需要zookeeper
• 3、kafka中的zookeeper起到什么作用
• 4、Mac 使用 docker 搭建 kafka 集群 + Zookeeper + kafka-manager
• 5、zookeeper在kafka作用

Zookeeper 在 Kafka 中的作用

如上图所示，kafaka集群的 broker，和 Consumer 都需要连接 Zookeeper。

Producer 直接连接 Broker。

Producer 把数据上传到 Broker，Producer可以指定数据有几个分区、几个备份。上面的图中，数据有两个分区 0、1，者迹每个分区都有自己的副本：0'、 1'。

黄色的分区为 leader，白色的为 follower。

leader 处理 partition 的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。 如下图所示，红色的为 leader，绿色的为 follower，leader复制自己到其他 Broker 中：

Topic 分区被放在不同的 Broker 中，保证 Producer 和 Consumer 错开访问 Broker，避免访问单个 Broker造成过度的IO压力，使得负载均衡。

Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的Broker管理起来 ，此时就使用到了Zookeeper。在Zookeeper上会有一个专门 用来进森告行Broker服务器列表记录 的节点：

/brokers/ids

每个Broker在启动时，都会到Zookeeper上进行注册，即到/brokers/ids下创建属于自己的节点，如/brokers/ids/[0...N]。

Kafka使用了全局唯一的数字来指代每个Broker服务器，不同的Broker必须使用不同的Broker ID进行注册，创建完节点后， 每个Broker就会将自己的IP地址和端口信息记录 到首春并该节点中去。其中，Broker创建的节点类型是临时节点，一旦Broker宕机，则对应的临时节点也会被自动删除。

在Kafka中，同一个 Topic的消息会被分成多个分区 并将其分布在多个Broker上， 这些分区信息及与Broker的对应关系 也都是由Zookeeper在维护，由专门的节点来记录，如：

/borkers/topics

Kafka中每个Topic都会以/brokers/topics/[topic]的形式被记录，如/brokers/topics/login和/brokers/topics/search等。Broker服务器启动后，会到对应Topic节点（/brokers/topics）上注册自己的Broker ID并写入针对该Topic的分区总数，如/brokers/topics/login/3-2，这个节点表示Broker ID为3的一个Broker服务器，对于"login"这个Topic的消息，提供了2个分区进行消息存储，同样，这个分区节点也是临时节点。

由于同一个Topic消息会被分区并将其分布在多个Broker上，因此， 生产者需要将消息合理地发送到这些分布式的Broker上 ，那么如何实现生产者的负载均衡，Kafka支持传统的四层负载均衡，也支持Zookeeper方式实现负载均衡。

(1) 四层负载均衡，根据生产者的IP地址和端口来为其确定一个相关联的Broker。通常，一个生产者只会对应单个Broker，然后该生产者产生的消息都发往该Broker。这种方式逻辑简单，每个生产者不需要同其他系统建立额外的TCP连接，只需要和Broker维护单个TCP连接即可。但是，其无法做到真正的负载均衡，因为实际系统中的每个生产者产生的消息量及每个Broker的消息存储量都是不一样的，如果有些生产者产生的消息远多于其他生产者的话，那么会导致不同的Broker接收到的消息总数差异巨大，同时，生产者也无法实时感知到Broker的新增和删除。

(2) 使用Zookeeper进行负载均衡，由于每个Broker启动时，都会完成Broker注册过程，生产者会通过该节点的变化来动态地感知到Broker服务器列表的变更，这样就可以实现动态的负载均衡机制。

与生产者类似，Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费者分组包含若干消费者， 每条消息都只会发送给分组中的一个消费者 ，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。

消费组 (Consumer Group)：

consumer group 下有多个 Consumer（消费者）。

对于每个消费者组 (Consumer Group)，Kafka都会为其分配一个全局唯一的Group ID，Group 内部的所有消费者共享该 ID。订阅的topic下的每个分区只能分配给某个 group 下的一个consumer(当然该分区还可以被分配给其他group)。

同时，Kafka为每个消费者分配一个Consumer ID，通常采用"Hostname:UUID"形式表示。

在Kafka中，规定了 每个消息分区 只能被同组的一个消费者进行消费 ，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：

/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]

其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该 消息分区 上 消费者的Consumer ID。

在消费者对指定消息分区进行消息消费的过程中， 需要定时地将分区消息的消费进度Offset记录到Zookeeper上 ，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:

/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]

节点内容就是Offset的值。

消费者服务器在初始化启动时加入消费者分组的步骤如下

注册到消费者分组。每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。

对 消费者分组 中的 消费者 的变化注册监听 。每个 消费者 都需要关注所属 消费者分组 中其他消费者服务器的变化情况，即对/consumers/[group_id]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。

对Broker服务器变化注册监听 。消费者需要对/broker/ids/[0-N]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。

进行消费者负载均衡 。为了让同一个Topic下不同分区的消息尽量均衡地被多个 消费者 消费而进行 消费者 与 消息 分区分配的过程，通常，对于一个消费者分组，如果组内的消费者服务器发生变更或Broker服务器发生变更，会发出消费者负载均衡。

以下是kafka在zookeep中的详细存储结构图：

早期版本的 kafka 用 zk 做 meta 信息存储，consumer 的消费状态，group 的管理以及 offse t的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中确实逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖

[img]

为什么Kafka需要zookeeper

为什么搭建Kafka需要zookeeper_百度知道

kafka 很多说不需要安装zk的是因为他们都使用了kafka自带码洞唤的zk

至于kafka为什么使用zk，你首先要知道zk的作用, 作为去中心化的集群模式。

需要要消费者知道现在那些生产者（对于消费者而言，kafka就是生产者）是可用的。

如果没了zk消迟凯费者如何知道呢？如果每次消费者在消费之前颤羡都去尝试连接生产者测试下是否连接成功，效率呢？

所以kafka需要zk，在kafka的设计中就依赖了zk了。

kafka中的zookeeper起到什么作用

zookeeper是一个分布式的协调组件，早期版本的kafka用zk做让段meta信息存储，consumer的消费状态，group的管理以及offset的值。

考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中友磨逐渐弱化了好滑斗zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖。

Mac 使用 docker 搭建 kafka 集群 + Zookeeper + kafka-manager

这里我们用最简单的方式创建一个独立的Zookeeper节点，如果要考虑zookeeper的高可用，可以将其做成一个集群，友中最好是能有多台机器。

默认的，容器内配置文件在，/conf/zoo.cfg，数据和日志目录默认在/data 和 /datalog，需要的话可以将上述目录映射到宿主机的可靠文件目录下。

使用docker命令可快速在同一台机器搭建多个kafka，只需要改变brokerId和端口

中间两个参数的 192.168.0.102 改为 宿主机器 的IP地址，如果不这么设置，可能会导致在别的机器上访问不到 kafka。

或者可以通过 kafka-manager 创建

在kafka容器中的 opt/kafka_2.12-1.1.0/ 目录下输入

显示每个分区的Leader机器为broker0，在broker0和1上具有备份，Isr代表存活的备份机器中存活的。

当停掉纤备kafka1后，

再查看topic状态，输出结果：

kafka-manager 有图形化UI，可以方便的监控集群状态，调整队列配置

容器启动以后访问主机的9000端口，0.0.0:9000

首次进入需要添加一个集群标识，如下图所示

配置好以后，通过Zookeeper该管理节点可以读取到整毁告毁个Kafka集群的信息，并且我们可以通过JMX直接看到集群的健康状态

也可以看到主题的读写速度，偏移量等信息，如下图所示：

Brokers ,Partitions,Replicas 都能看到

以及 group:

原文地址: mac 使用 docker搭建 kafka集群 + Zookeeper + kafka-manager

zookeeper在kafka作用

zookeeper在kafka作用如下：

Kafka将元数据信息保存在Zookeeper中，但是发送给袜神Topic本身的数据是不会发到Zk上的。枣好陪kafka使用zookeeper来实现动态的集群凳蠢扩展，不需要更改客户端（producer和consumer）的配置。

broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。

关于kafkazookeeper和kafkazookeeper迁移的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。