kafka系列 - 12 Kafka 消费者|消费方式|工作流程|消费者组原理|消费者组初始化和消费流程|消费者参数

本文详细介绍了Kafka消费者的消费方式,包括pull模式及其不足。消费者工作流程中强调了一个消费者可消费多个分区,而每个分区只能被消费者组内一个消费者消费。消费者组原理涉及组内消费者分工和分区分配。初始化流程涵盖了消费者加入组、选举leader、分配消费任务等步骤。消费者组消费流程包括发送消费请求、数据处理等环节。最后,文章列举了若干重要的消费者参数,如bootstrap.servers、group.id和auto.commit.interval.ms等,这些参数影响着消费者的性能和行为。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 消费方式

① pull 拉模式:consumer采用从broker中主动拉取数据。

② push 推模式:Kafka没有采用这种方式,因为由broker决定消息发送速率,很难适应所有消费者的消费速率。例如推送的速度是50m/s,Consumer1、Consumer2就来不及处理消息。

在这里插入图片描述

pull 模式不足之处是,如果Kafka没有数据,消费者可能会陷入循环中,一直返回空数据。

2. 消费者工作流程

在这里插入图片描述

① 一个消费者可以消费多个分区数据;

② 每个分区的数据只能由消费者组中一个消费者消费,同一个分区的数据不能由消费者组中的两个消费者消费;

③ 每个消费者的offset由消费者提交到系统主题保存;

3. 消费者组原理

Consumer Group(CG)消费者组:由多个consumer组成。形成一个消费者组的条件,是所有消费者的groupid相同。

  • 消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费。
  • 消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

在这里插入图片描述

如果向消费组中添加更多的消费者,超过主题分区数量,则有一部分消费者就会闲置,不会接收任何消息。

在这里插入图片描述

消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

在这里插入图片描述

4. 消费者组初始化流程

coordinator:辅助实现消费者组的初始化和分区的分配。

coordinator节点选择 = groupid的hashcode值 % 50( __consumer_offsets的分区数量)

例如: groupid的hashcode值 = 1,1% 50 = 1,那么__consumer_offsets 主题的1号分区,在哪个broker上,就选择这个节点的coordinator作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。

在这里插入图片描述

① 每个consumer都发送JoinGroup请求;

② 选出一个consumer作为leader;

③ 把要消费的topic情况发送给leader 消费者;

④ leader会负责制定消费方案;

⑤ 把消费方案发给coordinator;

⑥ Coordinator就把消费方案下发给各个consumer;

⑦ 每个消费者都会和coordinator保持心跳(默认3s),一旦超时(session.timeout.ms=45s),该消费者会被移除,并触发再平衡;或者消费者处理消息的时间过长(max.poll.interval.ms5分钟),也会触发再平衡

5. 消费者组消费流程

在这里插入图片描述

① 消费者组中的消费者调用 sendFetches 方法发送消费请求

  • FetchedRecords 从队列中抓取数据;
  • Fetch.min.bytes 每批次最小抓取大小,默认1字节;
  • etch.max.wait.ms 一批数据最小值未达到的超时时间,默认500ms;
  • Fetch.max.bytes 每批次最大抓取大小,默认50m;

② ConsumerNetworkClient 调用 send 方法发送请求

③ 调用回调 onSuccess 方法把对应的结果拉取过来,并放在一个队列中

④ 消费者从队列中抓取数据进行处理

  • Max.poll.records一次拉取数据返回消息的最大条数,默认500条;

⑤ 对数据进行反序列化

⑥ 拦截器处理

⑦ 数据处理

6. 消费者重要参数

  • bootstrap.servers:向 Kafka 集群建立初始连接用到的 host/port 列表。
  • key.deserializer 和value.deserializer:指定接收消息的 key 和 value 的反序列化类型,一定要写全类名;
  • group.id 标记消费者所属的消费者组。
  • enable.auto.commit 默认值为 true,消费者会自动周期性地向服务器提交偏移量。
  • auto.commit.interval.ms 如果设置了 enable.auto.commit 的值为 true, 则该值定义了消费者偏移量向 Kafka 提交的频率,默认 5s。
  • auto.offset.reset 当 Kafka 中没有初始偏移量或当前偏移量在服务器中不存在(如,数据被删除了),该如何处理?
    • earliest:自动重置偏移量到最早的偏移量。
    • latest:默认,自动重置偏移量为最新的偏移量。
    • none:如果消费组原来的(previous)偏移量不存在,则向消费者抛异常。 anything:向消费者抛异常。
  • offsets.topic.num.partitions __consumer_offsets 的分区数,默认是 50 个分区。
  • heartbeat.interval.ms Kafka 消费者和 coordinator 之间的心跳时间,默认 3s。该 条目 的值必 须小于 session.timeout.ms , 也不 应该 高于session.timeout.ms 的 1/3。
  • session.timeout.ms Kafka 消费者和 coordinator 之间连接超时时间,默认 45s。超过该值,该消费者被移除,消费者组执行再平衡。
  • max.poll.interval.ms 消费者处理消息的最大时长,默认是 5 分钟。超过该值,该消费者被移除,消费者组执行再平衡。
  • fetch.min.bytes 默认 1 个字节。消费者获取服务器端一批消息最小的字节数。
  • fetch.max.wait.ms 默认 500ms。如果没有从服务器端获取到一批数据的最小字节数。该时间到,仍然会返回数据。
  • fetch.max.bytes 默认 Default: 52428800(50 m)。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值(50m)仍然可以拉取回来这批数据,因此,这不是一个绝对最大值 。 一 批 次 的 大 小 受 message.max.bytes ( brokerconfig)or max.message.bytes (topic config)影响。
  • max.poll.records 一次 poll 拉取数据返回消息的最大条数,默认是 500 条。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我一直在流浪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值