🍒今天是端午节,先祝大家端午节快乐!上一期我们学习了kafka的broker部分主要介绍了kafka中的副本、kafka文件的存储的原理,以及kafka的高效读写的保证,今天我们来介绍kafka中的消费者原理,对往期内容感兴趣的小伙伴可以参考👇:
🍑消费者作为kafka中最重要的部分,如何从主题中消费数据是我们重点关注的地方,话不多说,让我们开始今日份的学习吧!
通常来说,消费者消费数据的方式有2种,一种是拉取数据的方式,另一种是broker主动推数据。
kafka中,消费者采用的消费数据的方式是拉取数据的模式,主动从broker中拉取数据。(如果broker中没有数据,可能会造成拉取为空的死循环。)
push模式是指broker主动向消费者推送数据,但是由于每个消费者的消费速率不太一样,导致推送的速率很难适应所有的消费者。
初学者对于消费者和消费者组的概念容易搞混,本章在这里单独拿出来讲解。
消费者:消费者就是我们所说的consumer,consumer可以消费主题分区的数据,且相互之间互不影响。
消费者组存在的意义: 应用程序需要创建一个消费者对象,订阅kafka的主题并开始接收消息,然后验证消息并保存结果。可是生产者产生消息的速度超过了应用程序验证数据的速度,这个时候该怎么办?这个时候,就需要对消费者进行横向伸缩,有点像多个生产者向同一个主题写入消息一样,我们也可以使用多个消费者从同一个主题读取消息,对消息进行分流,而这多个消费者组成的组就是消费者组。
注:Kafka 消费者从属于消费者群组。一个群组里的消费者订阅的是同一个主题,每个消费者接收主题一部分分区的消息。
第一种情况,如下图,消费者组1中含有一个消费者1,需要消费主题T1中的数据,消费者1将接受主题T1中4个分区的数据。
第二种情况,如下图,消费者组1中新增了一个消费者2,需要消费主题T1中的数据,消费者1接受主题T1中0,2分区的数据;消费者2将接受主题T1中1,3分区的数据。
第三种情况,如下图,消费者组1中有4个消费者1,2,3,4,需要消费主题T1中的数据,则每个分区都消费都消费一个主题分区的数据。
第四种情况,消费者组1中的消费者个数多于主题分区个数,多余的消费者会被闲置。
除了通过增加一个消费者组中的消费者个数来横向伸缩单个应用程序外,还经常出现多个应用程序从同一个主题读取数据的情况。这种需求只要保证每个应用程序有自己的消费者群组,就可以让它们获取到主题所有的消息。不同于传统的消息系统,横向伸缩 Kafka 消费者和消费者群组并不会对性能造成负面影响。
如下图,增加了一个消费者组2,虽然他们俩消费同一个主题的数据,但是消费者组2和消费者组1之间没有半毛钱关系,各自独立运行。
总的来说,需要注意以下2点:
这里介绍一下,producer向集群的每一个leader发送数据,一批一批的发送,然后follower主动向leader同步数据,然后消费者和消费者组主动拉取数据进行消费,一个消费者或者消费者组可以消费多个分区的数据,消费数据的位置信息由offset进行存储,offset保存在系统主题consumer_offsets中(旧版本offset是维护在zookeeper中)。
这里先介绍一个概念:
例如: groupid的hashcode值 = 1,1% 50 = 1,那么__consumer_offsets 主题的1号分区,在哪个broker上,就选择这个节点的coordinator作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。
消费者的消费流程如下,我们来详细解释一下:
注:这个过程中每个消费者都会和coordinator保持心跳默认3s(定期联系),上限是45s,如果45s内没有联系到该消费者,那么 coordinator会认为该消费者出现故障,将它移除,并触发再平衡;或者消费者处理数据的时间过长(5分钟以上)那么也会触发再平衡。
上面介绍完了消费者初始化的流程,接下来就是消费者详细消费数据的流程:
左侧是kafka对应的集群,右侧是我们对应的消费者组,中间是消费者与集群的网络连接。
-《尚硅谷大数据技术之 Kafka》
-《kafka权威指南》
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://liuxiaocong.blog.csdn.net/article/details/125107152
内容来源于网络,如有侵权,请联系作者删除!