Kafka集群直接通信原理

文章目录

• • 概要
  • 整体架构流程
  • 技术名词解释
  • 技术细节
  • 小结

概要

当前跟着课程配置好了zookeeper集群和Kafka集群，学习操作之前首先了解他俩集群是如何构建的，框架需要了解。

整体架构流程

这是Kafka和zookeeper交互的基础架构，可以看出主要有四部分：生产者Producer、消费者Consumer、Kafka集群服务器、zookeeper服务器。

生产者和消费者通过网络客户端与Kafka集群通信，生产者可以传输消息到Kafka集群上指定的主题，消费者可以从Kafka集群上指定的主题获取消息。

 Kafka集群里：每一台节点上都存在网络服务器和网络客户端，用来保持与其他节点/生产者/消费者之间进行通信，每台节点上都有zookeeper的客户端zkClient，用来与zookeeper服务器进行通信，Kafka集群里存在一个Controller节点（即leader）,其他节点可以作为备选controller，当Controller节点宕机/无法连接时，其他备选节点可以通过zookeeper进行投票机制选出新的Controller节点。

每台Kafka节点支持对数据进行分区/副本存储，所以每台节点上存在管理数据/副本的manager，即replicationManager（副本管理器），LogManager（日志管理器 因为Kafka早起就是做日志信息存储的所以用这个名称管理数据），每台节点里存的分区数据只有在该节点上访问才允许读写操作，其他节点存储该节点的副本无法读写，即副本分为Leader和Follower，Leader就是存在本节点的数据，follower就是存在其他节点上的副本。

Kafka的broker节点与zookeeper通信步骤（三节点）

当我们首先启动zookeeper，还未启动Kafka集群时，此时zookeeper里保存Kafka集群信息的节点还没有数据，一些重要的节点：例如broker节点下的id子节点，controller节点里都没有数据。

接下来启动Kafka集群（三台服务器）那么将会有三个broker-id，他们回去争夺controller，对于Kafka选举controller的机制较为简单，即那个broker节点先把信息注册到controller节点里该节点就变成controller，那么对于最快启动的第一个broker节点来说，它会进行上述4个步骤：

1.在zookeeper/brokers/ids子节点下注册，此时该broker的id会写入/ids节点

2.此时该broker不知道zookeeper的/controller下是否已经有注册的controller节点，它会监听/controller

3.由于它是第一个broker，所以/controller里不存在注册的controller节点，它会在/controller里注册节点，此时它会成功注册 成为controller节点

4.它成功变成controller节点后，会监听zookeeper里/brokers/ids下的节点信息，后面来的broker对/brokers/ids的修改它会及时得到更新。

第一个broker与zookeeper通信后，第二个broker和zookeeper进行通信，同样的：

1.它先在/brokers/ids注册它自己的broker-id

2.由于它也是新加入的broker，它不知道controller里是否有已经注册的broker信息，它会对/controller进行监听

3.它监听发现已经有注册的controller（即broker 1），它接下来的行为 向/controller里注册自己的broker-id 会失败

4.broker 1 作为controller，它监听了/brokers/ids下的节点数据，由于broker 2在该节点路径下修改了数据（把自己的broker-id加入进去），broker 1会收到更新

5.broker 1收到更新后 会通知集群里其他非controller的broker，此时集群里只有两个broker，所以它会通知broker 2 ，将集群相关的元数据发送给broker 2

接下来集群里最后一个broker与zookeeper通信，还是同样的：

1.它首先在/brokers/ids里注册自己的broker-id信息

2.它一样会监听/controller看是否已经有broker注册成controller

3.它发现已经有controller后它向/controller里注册自己的broker-id会失败

4.broker 1会收到broker 3在/brokers/ids里更新的broker-id

5.broker 1会向集群里其他非controller的broker发送集群相关的元数据

以上就是在zookeeper启动环境下 首次启动Kafka集群时，Kafka服务器broker是如何与zookeeper进行通信 并写入相应信息到zookeeper节点下的原理。

当/controller节点下保存的broker-id信息丢失时会如何呢？

使用prettyzoo可以查看zookeeper具体节点的可视化工具，当Kafka集群完全启动后，能发现此时/brokers/ids里保存了三个id信息，并且/controller下也有broker-id：2 意味着该id对应的broker成为了controller，此时如果我们人为删去/controller，意味着broker 0 1 2三台服务器监听的/controller节点信息发生改变，从有注册信息-->没有注册信息，于是三台broker会开始争夺controller，然后决定出新的controller。