Kafka学习笔记——消费者

最新推荐文章于 2024-07-21 18:15:30 发布

xianrenzw

最新推荐文章于 2024-07-21 18:15:30 发布

阅读量135

点赞数 1

文章标签： kafka 学习笔记

本文链接：https://blog.csdn.net/xianrenzw/article/details/131973920

版权

Kafka学习笔记——消费者

消费方式

pull （拉）模式：consumer采用从broker中主动拉取数据。Kafka采用这种方式。

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

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

消费者工作流程

1. 消费者组原理

Consumer Group（CG）：消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的 groupid 相同。

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

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

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

2. 消费者组初始化流程

如图所示
在这里插入图片描述

两个重要参数（面试常考，生产环境有用）：

消费者和 coordinator 保持通信超时时间：45秒
消费者处理消息超时：5分钟

3. 消费者组消息消费流程

1）创建一个 ConsumerNetworkClient 用来跟 kafka 集群进行交互
2）调用 sendFetches 方法，用来进行抓取数据的初始化
3）准备好参数：Fetch.min.bytes 每批次最小抓取大小，默认1字节；fetch.max.wait.ms一批数据最小值未达到的超时时间，默认500ms；Fetch.max.bytes每批次最大抓取大小，默认50m。。。
4）调用 send 方法，向集群发送请求
5）通过回调方法 onSuccess 把对应结果拉取回来（一批一批拉），并放到一个消息队列 completedFetches（queue）里面
6）拉取上一步的返回消息并将数据反序列化
7）经过拦截器（处理数据，如果有）

详见下图

在这里插入图片描述

消费者重要参数

参数名称	描述
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 条。
partition.assignment.strategy	消费者分区分配策略，默认策略是 Range + CooperativeSticky 。Kafka 可以同时使用多个分区分配策略。可以选择的策略包括： Range 、 RoundRobin 、 Sticky 、CooperativeSticky

消费者 API

常用 API :

// 创建消费者的配置对象
Properties properties = new Properties();
// 连接到 kafka 集群
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
// 配置序列化 跟据KV类型来改参数 下面以String演示
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 配置消费者组（组名任意起名） 必须设置，相同组名的消费者会自动分配到同一个组
properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test");
// 创建消费者对象
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(properties);
// 指定消费某个主题的某个分区数据
ArrayList<TopicPartition> topicPartitions = new ArrayList<>();
topicPartitions.add(new TopicPartition("first", 0));
kafkaConsumer.assign(topicPartitions);
// 拉取数据 
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));

分区的分配以及再平衡

一个consumer group中有多个consumer组成，一个 topic 有多个 partition 组成，到底由哪个consumer 来消费哪个partition 的数据呢？

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

分区分配策略之 Range

1. 原理

Range 是针对每个 topic 而言的。

首先对同一个 topic 里面的分区按照序号排序，并对消费者按照字母顺序排序。假如现在有7个分区、3个消费者，排序后的分区会是0，1，2，3，4，5，6；消费者排完序后将会是 C0 ，C1 , C2。
通过 partitions数除以 consumer数 来决定每个消费者应该消费几个分区。如果除不尽，那么前面几个消费者将会多消费一些分区。
例如，7/3 = 2 余 1 ，除不尽，则消费者 C0 便会多消费一个分区；8/3 = 2 余 2 ，C0 和 C1 分别多消费一个

如果有 N 多个 topic ，那么对前面几个消费者的负担很大，容易产生数据倾斜！

2. Range 分区分配再平衡案例

以上面的 7分区3消费者为例，当 0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，这段时间组内其他消费者还是按照自己原本的任务来执行，时间到了 45s 后，判断消费者 0 已经挂掉，消费者 0 会被踢出消费者组，然后重新按照 range 方式把 0 号消费者的任务分配给其他消费者执行。

分区分配策略之 RoundRobin

1. 原理

RoundRobin 针对集群中所有 topic 而言。

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

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

2. RoundRobin 分区分配再平衡案例

还是以刚刚的 7分区3消费者为例，0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务按照 RoundRobin 方式分配给其他消费者执行。

0号挂掉前：
0 号消费者：消费到 0、3、6 号分区数据
1 号消费者：消费到 1、4 号分区数据
2 号消费者：消费到 2、5 号分区数据

0号挂掉（45s）后：
1 号消费者：消费到 0、2、4、6 号分区数据（全偶数）
2 号消费者：消费到 1、3、5 号分区数据（全奇数）

分区分配策略之 Sticky（粘性分区）

1. 原理

粘性分区定义：可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。

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

// 修改分区分配策略  由于Kafka可以同时使用多个分区分配策略，所以可以使用集合来传参
ArrayList<String> startegys = new ArrayList<>();
startegys.add("org.apache.kafka.clients.consumer.StickyAssignor");
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, startegys);

2. Sticky 分区分配再平衡案例

还是以刚刚的 7分区3消费者为例，0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他消费者执行

0号挂掉前：
0 号消费者：消费到 0、3、6 号分区数据
1 号消费者：消费到 1、4 号分区数据
2 号消费者：消费到 2、5 号分区数据

0号挂掉（45s）后：
1 号消费者：消费到 1、 4、 0、6 号分区数据
2 号消费者：消费到 2、 5、 3 号分区数据
可以看到 Sticky 会尽量保持原有分配

offset 位移

offset 的默认维护位置

Kafka0.9版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从0.9版本开始， consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为**__consumer_offsets** 。

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

__consumer_offsets 主题是系统主题，默认情况下不可以通过消费者进行消费。在配置文件 config/consumer.properties 中添加配置 exclude.internal.topics=false（原本为ture），就可以查看该系统主题数据。

在 kafka 安装目录下查看消费者消费主题__consumer_offsets。（固定 API ）

bin/kafka-console-consumer.sh --topic consumer_offsets --bootstrap-server hadoop102:9092 --consumer.config config/consumer.properties --formatter "kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter" --from-beginning

看到大量类似下面的信息

在这里插入图片描述

[offset,atguigu,0] 就是 group.id+topic+分区号，

offset 的提交

默认情况下，为了使我们能够专注于自己的业务逻辑，Kafka 提供了**自动提交 offset **的功能。如图所示：

在这里插入图片描述

参数名称	描述
enable.auto.commit	默认值为 true，消费者会自动周期性地向服务器提交偏移量。
auto.commit.interval.ms	如果设置了 enable.auto.commit 的值为 true ，则该值定义了消费者偏移量向 Kafka 提交的频率，默认 5s。

指定 offset 的消费

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

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

（1）earliest：自动将偏移量重置为最早的偏移量，–from-beginning。

（2）latest（默认值）：自动将偏移量重置为最新偏移量。

（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常。

当然，我们也可以任意指定 offset 位移开始消费，相关 API 如下

// 1 创建一个消费者
KafkaConsumer<String,  String>  kafkaConsumer  =  new KafkaConsumer<>(properties);
// 2 订阅一个主题
ArrayList<String> topics = new ArrayList<>(); 
topics.add("first");
kafkaConsumer.subscribe(topics);

// 获取消费者分区分配信息（有了分区分配信息才能指定从哪个分区的哪个offset开始消费） 
Set<TopicPartition> assignment = kafkaConsumer.assignment();
// 保证该分区分配方案已经制定完成 
while (assignment.size() == 0) {
		kafkaConsumer.poll(Duration.ofSeconds(1));
  	// 在循环内部不断更新 assignment 
 		assignment = kafkaConsumer.assignment();
}
// 遍历所有分区，并指定 offset 从 1700 的位置开始消费
for (TopicPartition tp: assignment) {
		kafkaConsumer.seek(tp, 1700);
}

指定时间消费

上面我们指定了 offset 位置进行消费，我们还可以指定时间来进行消费，其本质上还是按 offset 来消费，只不过调用了相关的 API 来将时间对应的 offset 获取到，下面是一个从当前系统时间的前一天开始获取数据的案例的部分代码，相关 API 如下，消费者的创建与主题订阅同上

// 获取消费者分区分配信息（有了分区分配信息才能指定从哪个分区的哪个offset开始消费）
Set<TopicPartition> assignment = kafkaConsumer.assignment();
// 保证该分区分配方案已经制定完成
while (assignment.size() == 0) {
    kafkaConsumer.poll(Duration.ofSeconds(1));
    // 在循环内部不断更新 assignment
    assignment = kafkaConsumer.assignment();
}
// 希望把时间转化成对应的 offset，发现 offsetsForTimes 方法需要传递一个集合
HashMap<TopicPartition, Long> topicPartitionLongHashMap = new HashMap<>();
// 封装对应的集合
for (TopicPartition topicPartition : assignment) {
    // 这是希望从当前系统时间的 前一天 开始获取数据
    topicPartitionLongHashMap.put(topicPartition,System.currentTimeMillis() - 1 * 24 * 3600 * 1000);
}
Map<TopicPartition, OffsetAndTimestamp> topicPartitionOffsetAndTimestampMap = kafkaConsumer.offsetsForTimes(topicPartitionLongHashMap);
// 遍历所有分区，并指定 从一天前 所在的offset开始消费
for (TopicPartition tp : assignment) {
    OffsetAndTimestamp offsetAndTimestamp = topicPartitionOffsetAndTimestampMap.get(tp);
    kafkaConsumer.seek(tp, offsetAndTimestamp.offset());
}

漏消费和重复消费

重复消费：已经消费了数据，但是 offset 没提交。一般由自动提交 offset 引起
漏消费：先提交 offset 后消费，有可能会造成数据的漏消费。一般由手动提交 offset 引起

在这里插入图片描述

消费者事务

如果想完成Consumer端的精准一次性消费，那么需要Kafka消费端将消费过程和提交offset 过程做原子绑定。此时我们需要将Kafka 的offset 保存到支持事务的自定义介质（比如 MySQL）。
上游从生产者到 kafka 集群做到至少一次，下游消费者必须支持事务，才能做到精确一次性消费。