招远做网站app营销十大成功案例

前置知识

Kafka基本概念https://blog.csdn.net/dxh9231028/article/details/141270920?spm=1001.2014.3001.5501

1. Kafka集群启动

Kafka在启动集群中的各个broker时，broker会向controller注册自己，并且从controller节点同步集群元数据。

broker是Kafka集群中的一个角色，Kafka集群中有两个角色，分别是broker和controller。其中broker服务生产和消费数据，以及集群中数据同步等，而controller则是负责协调各个broker，维护集群的元数据信息，那么什么是集群的元数据。

Kafka集群中由生产者生产的数据叫消息，而集群的状态信息，如集群节点信息，主题信息，主题分区信息，等等。

在传统的zookeeper模式下，所有节点都有broker角色，并在集群启动时会选择一个broker节点作为controller节点，其他节点从zookeeper集群中存储和拉取集群元数据，controller负责将各种集群元数据信息的更改注册到zookeeper集群中。 

而在Kraft模式下，集群元数据交由Kafka自身管理，集群中各个节点可以在broker和controller中通过配置项选择自己的角色（可以两个都选择），而被选择为controller的节点会在内部进行选举，选举出一个真正的controller，而其他未被选举为controller的节点则是在当前controller的节点意外宕机时发挥作用。

由于所有broker节点都需要向controller节点发起注册，所以在Kraft模式下，controller节点选举出来之前，其他节点无法正常启动。而Zookeeper中controller的选举时通过各个broker节点在zookeeper集群中创建临时有序节点来竞争controller角色，所以只需要一个broker就可以完成选举。

2. controller选举流程

当集群第一次启动或集群中的controller角色节点宕机时会触发controller的重新选举，在zookeeper模式和kraft模式下，两者略有不同。

zookeeper模式

在zookeeper模式下，在集群第一次启动时会创建临时有序节点来争夺controller角色，在当前controller角色意外宕机后，zookeeper会查找当前的临时有序节点中序号最小的broker，继续当controller，换句话说，谁先启动，谁当controller。这一过程在上面的图片中已经很好的解释了。

kraft模式

在kraft模式下，集群节点通过具有controller角色的节点来进行controller节点的选举和投票。在Kafka集群正常运行的过程中其他为当选controller的controller角色节点会持续的和当前controller维持心跳机制，当未当选节点发送的心跳信号在一定时间内的不到回应时，其会认为当前controller已经宕机，然后这个节点会变为candidate节点。

candidate携带着任期号和日志信息，向其他带有controller角色的节点发起投票。candidate节点首先会提高自己的任期号（初始值是0），向其他的节点发起投票请求，其他节点在接收请求时会比较任期号和日志信息，判断对方的信息是否比自己的信息更新。如果对方的信息更新，那么则会投票给对方，并且将自己的任期号更新至和对方一样（如果日志信息不满足，但任期号比自己大，当前节点也不会投票给对方，不过仍然会更新自己的任期号）。

当一个candidate获取了大多数节点的投票后则会当选新的controller，不过因为其并没有获取全部节点投票，所以其仍然有可能没有一部分节点的数据内有的数据，所以其他在上任controller后还要向其他节点拉取数据，以保证不丢失数据。

3. 消息生产和消费流程

当controller成功选举后，broker可以成功完成注册，Kakfa集群就可以成功启动，紧接着便可以开始进行消息的生产和消费 。

消息的真题流程包括生产生产消息，经过序列化变成二进制数组后传入Kafka集群的制定主题，通过轮训算法进入制定分区。消费者组则在组协调器的指挥下，消费者消费组协调器指定的分区，并获取对应分区当前消费分区的偏移量。具体流程如下图

 这是主题只有一个副本的情况下，当我们创建主题制定多个副本时，Kafka集群会创建当前主题的多个副本，并分别存储在不同的broker中，并且副本数量可以随意指定，但不能超过broker数量，这也就是说一个主题可能会出现在其中一些broker，而不是全部borker。

不过这并不会影响到集群功能，因为虽然有些broker没有对应的主题，但其中保存的集群元数据却记录了哪些broker有这个主题，所以broker依旧可以操作对应主题的数据。

Kafka并不会讲生产者生产的消息发往所有的主题副本，因为消息数量通常很多，如果Kafka讲每个消息都发送多份，势必会极大的影响Kafka的性能，所以主题之间也存在着数据同步的过程。而既然数据同步的过程即然存在，那么也就必然会存在着Leader和Follower的关系，不过这种关系并非建立在主题之间，而是建立在分区之间，换句话说，不存在某个主题副本是leader，而是当前主题副本的某个分区副本是Leader，其他主题副本的分区从这个Leader中同步数据，并且一个主题副本也不是其中所有的分区都是Leader，而是有的分区是Leader，有的是Follower，这样说起来很难理解，所以假设我们在三主机集群中创建三分区的主题副本，创建三份，内容如下图：

可以看到图中三个分区分别有三个Leader，而这三个Leader也分布在三个主题副本之，Kafka在实际的Leader分布上，也会尽可能做到平均分布，一方面是因为Leader主要处理消息的进入，如果都集中在一个borker上，会造成压力过大。另一方面，Leader中保存着整个主题的最新数据，如果某一个主机宕机，也可以防止因为意外，所有Leader数据丢失。