Kafka消费者组整合代码实现分区分配策略以及offset使用场景

Consumer Group(CG):消费者组,由多个…

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

• 消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费。

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

消费者组初始化流程

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

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

1)每个consumer都 发送JoinGroup请求

2)选出一个 consumer作为leader

3)把要消费的topic情况 发送给leader 消费者

4)leader会负 责制定消费方案

5)把消费方案发给coordinator

6)Coordinator就把消费方 案下发给各个consumer

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

注意:在消费者 API 代码中必须配置消费者组 id。命令行启动消费者不填写消费者组 id 会被自动填写随机的消费者组 id

代码实现

指定消费某一分区

分区分配策略

当启动多个消费者消费时,消费者会自动分区消费,每个消费者消费对应分区的内容

Kafka有四种主流的分区分配策略: Range、RoundRobin、Sticky、CooperativeSticky。 可以通过配置参数partition.assignment.strategy,修改分区的分配策略。默认策略是Range + CooperativeSticky。Kafka可以同时使用 多个分区分配策略

Range 是对每个 topic 而言的。 首先对同一个 topic 里面的分区按照序号进行排序,并 对消费者按照字母顺序进行排序

假如现在有 7 个分区,3 个消费者,排序后的分区将会 是0,1,2,3,4,5,6;消费者排序完之后将会是C0,C1,C2,通过 partitions数/consumer数 来决定每个消费者应该 消费几个分区。如果除不尽,那么前面几个消费者将会多 消费 1 个分区。

RoundRobin 以及再平衡

RoundRobin 轮询分区策略,是把所有的 partition 和所有的 consumer 都列出来,然后按照 hashcode 进行排序,最后 通过轮询算法来分配 partition 给到各个消费者。

再平衡

停止掉 0 号消费者,重新发送消息(45s 以内)

0 号消费者的任务会按照 RoundRobin 的方式,把数据轮询分成不同区域,由其他消费者执行

(45s 以后)消费者 0 已经被踢出消费者组

// 修改分区分配策略
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFI
G, "org.apache.kafka.clients.consumer.RoundRobinAssignor");

Sticky 以及再平衡

粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略,首先会尽量均衡的放置分区 到消费者上面,在出现同一消费者组内消费者出现问题的时候,会尽量保持原有分配的分 区不变化。

类似于range,但粘性分区是随机的

// 修改分区分配策略
ArrayList<String> startegys = new ArrayList<>();
startegys.add("org.apache.kafka.clients.consumer.StickyAssignor");
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,
startegys);

offset 位移

offset存在系统主题里,避免与zookeeper交互,带来大量的网络通信

查看系统主题内容,在配置文件 config/consumer.properties 中添加配置 exclude.internal.topics=false,

默认是 true,表示不能消费系统主题。为了查看该系统主题数据,所以该参数修改为 false

消费者

bin/kafka-console-consumer.sh –bootstrap-server 192.168.100:9092 –topic test –group test

查看消费者消费主题__consumer_offsets

bin/kafka-console-consumer.sh –topic
__consumer_offsets –bootstrap-server 192.168.100:9092192.168.100:9092 –consumer.config config/consumer.properties –formatter
"kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageForm
atter" –from-beginning

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+ 分区号,value 就是当前 offset 的值。每隔一段时间,kafka 内部会对这个 topic 进行 compact,也就是每个 group.id+topic+分区号就保留最新数据

自动提交offset

enable.auto.commit:是否开启自动提交offset功能,默认是true

auto.commit.interval.ms:自动提交offset的时间间隔,默认是5s

// 是否自动提交 offset
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,
true);
// 提交 offset 的时间周期 1000ms,默认 5s
properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG,
1000);

手动提交 offset

手动提交offset的方法有两种:分别是commitSync(同步提交)和commitAsync(异步提交)。两者的相 同点是,都会将本次提交的一批数据最高的偏移量提交;不同点是,同步提交阻塞当前线程,一直到提交成 功,并且会自动失败重试;而异步提交则没有失败重试机制,故 有可能提交失败。

• commitSync(同步提交):必须等待offset提交完毕,再去消费下一批数据。

• commitAsync(异步提交) :发送完提交offset请求后,就开始消费下一批数据了。

同步提交 offset

异步提交 offset

指定 Offset 消费

auto.offset.reset = earliest | latest | none 默认是 latest

当 Kafka 中没有初始偏移量(消费者组第一次消费)或服务器上不再存在当前偏移量 时(例如该数据已被删除),该怎么办?

(1)earliest:自动将偏移量重置为最早的偏移量,–from-beginning。

(2)latest(默认值):自动将偏移量重置为最新偏移量。

(3)none:如果未找到消费者组的先前偏移量,则向消费者抛出异常

任意指定 offset 位移开始消费

注意:每次执行完,需要修改消费者组名;

指定时间消费

需求:在生产环境中,会遇到最近消费的几个小时数据异常,想重新按照时间消费。 例如要求按照时间消费前一天的数据,怎么处理?

漏消费和重复消费

重复消费:已经消费了数据,但是 offset 没提交。 漏消费:先提交 offset 后消费,有可能会造成数据的漏消费。

场景1:重复消费。自动提交offset引起

1) Consumer 每5s提交offse

2)如果提交offset后的2s,consumer挂了

3)再次重启consumer,则从上一次提交的 offset处继续消费,导致重复消费

漏消费

设置offset为手动提交,当offset被提交时,数据还在内存中未落盘,此时刚好消费者线 程被kill掉,那么offset已经提交,但是数据未处理,导致这部分内存中的数据丢失

如果想完成Consumer端的精准一次性消费,那么需要Kafka消费端将消费过程和提交offset 过程做原子绑定。此时我们需要将Kafka的offset保存到支持事务的自定义介质

数据积压

1)如果是Kafka消费能力不足,则可以考虑增 加Topic的分区数,并且同时提升消费组的消费者 数量,消费者数 = 分区数

2)如果是下游的数据处理不及时:提高每批次拉取的数 量。批次拉取数据过少(拉取数据/处理时间 < 生产速度), 使处理的数据小于生产的数据,也会造成数据积压

本文来自网络,不代表软粉网立场,转载请注明出处:https://www.rfff.net/p/6278.html

作者: HUI

发表评论

您的电子邮箱地址不会被公开。

返回顶部