Kafka运行机制(一):Kafka集群启动,controller选举,生产消费流程

本文主要是介绍Kafka运行机制(一):Kafka集群启动,controller选举,生产消费流程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前置知识

Kafka基本概念icon-default.png?t=N7T8https://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数据丢失。

这篇关于Kafka运行机制(一):Kafka集群启动,controller选举,生产消费流程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1090880

相关文章

Security OAuth2 单点登录流程

单点登录(英语:Single sign-on,缩写为 SSO),又译为单一签入,一种对于许多相互关连,但是又是各自独立的软件系统,提供访问控制的属性。当拥有这项属性时,当用户登录时,就可以获取所有系统的访问权限,不用对每个单一系统都逐一登录。这项功能通常是以轻型目录访问协议(LDAP)来实现,在服务器上会将用户信息存储到LDAP数据库中。相同的,单一注销(single sign-off)就是指

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

服务器集群同步时间手记

1.时间服务器配置(必须root用户) (1)检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 (2)修改ntp配置文件 [r

HDFS—集群扩容及缩容

白名单:表示在白名单的主机IP地址可以,用来存储数据。 配置白名单步骤如下: 1)在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 (1)创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称,假如集群正常工作的节

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

NameNode内存生产配置

Hadoop2.x 系列,配置 NameNode 内存 NameNode 内存默认 2000m ,如果服务器内存 4G , NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列,配置 Nam

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

springboot3打包成war包,用tomcat8启动

1、在pom中,将打包类型改为war <packaging>war</packaging> 2、pom中排除SpringBoot内置的Tomcat容器并添加Tomcat依赖,用于编译和测试,         *依赖时一定设置 scope 为 provided (相当于 tomcat 依赖只在本地运行和测试的时候有效,         打包的时候会排除这个依赖)<scope>provided

内核启动时减少log的方式

内核引导选项 内核引导选项大体上可以分为两类:一类与设备无关、另一类与设备有关。与设备有关的引导选项多如牛毛,需要你自己阅读内核中的相应驱动程序源码以获取其能够接受的引导选项。比如,如果你想知道可以向 AHA1542 SCSI 驱动程序传递哪些引导选项,那么就查看 drivers/scsi/aha1542.c 文件,一般在前面 100 行注释里就可以找到所接受的引导选项说明。大多数选项是通过"_

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3