Kafka3.x进阶

来源:B站

目录

Kafka生产者

生产经验------生产者如何提高吞吐量

java 复制代码
package com.jjm.kafka.producer;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;
public class CustomProducerParameters {
	 public static void main(String[] args) throws InterruptedException {
		 // 1. 创建 kafka 生产者的配置对象
		 Properties properties = new Properties();
		 // 2. 给 kafka 配置对象添加配置信息:bootstrap.servers
		 properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
		 
		 // key,value 序列化(必须):key.serializer,value.serializer
		 properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
		 
		 properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
		 // batch.size:批次大小,默认 16K
		 properties.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
		 // linger.ms:等待时间,默认 0
		 properties.put(ProducerConfig.LINGER_MS_CONFIG, 1);
		 // RecordAccumulator:缓冲区大小,默认 32M:buffer.memory
		 properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG,33554432);
		 // compression.type:压缩,默认 none,可配置值 gzip、snappy、lz4 和 zstd
		properties.put(ProducerConfig.COMPRESSION_TYPE_CONFIG,"snappy");
		 // 3. 创建 kafka 生产者对象
		 KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);
		 // 4. 调用 send 方法,发送消息
		 for (int i = 0; i < 5; i++) {
			kafkaProducer.send(new 
			ProducerRecord<>("first","atguigu " + i));
		 }
		 // 5. 关闭资源
		 kafkaProducer.close();
	 }
}

测试:

①在 hadoop102 上开启 Kafka 消费者。

sh 复制代码
[jjm@hadoop103 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first

②在 IDEA 中执行代码,观察 hadoop102 控制台中是否接收到消息。

sh 复制代码
[jjm@hadoop102 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first
atguigu 0
atguigu 1
atguigu 2
atguigu 3
atguigu 4

生产经验------数据可靠性

0)回顾发送流程

1)ack 应答原理

ACK应答级别

当acks=0时

当acks=1时

当acks=-1时

思考 :Leader收到数据,所有Follower都开始同步数据,但有一个Follower,因为某种故障,迟迟不能与Leader进行同步,那这个问题怎么解决呢?

Leader维护了一个动态的in-sync replica set(ISR),意为和Leader保持同步的Follower+Leader集合(leader:0,isr:0,1,2)。

如果Follower长时间未向Leader发送通信请求或同步数据,则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定,默认30s 。例如2超时,(leader:0, isr:0,1)。这样就不用等长期联系不上或者已经故障的节点。
数据可靠性分析:

如果分区副本设置为1个,或 者ISR里应答的最小副本数量( min.insync.replicas 默认为1)设置为1,和ack=1的效果是一样的,仍然有丢数的风险(leader:0,isr:0)。
数据完全可靠条件 = ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2
可靠性总结

acks=0,生产者发送过来数据就不管了,可靠性差,效率高

acks=1,生产者发送过来数据Leader应答,可靠性中等,效率中等

acks=-1,生产者发送过来数据Leader和ISR队列里面所有Follwer应答,可靠性高,效率低

在生产环境中,acks=0很少使用;acks=1,一般用于传输普通日志,允许丢个别数据;acks=-1,一般用于传输和钱相关的数据,对可靠性要求比较高的场景

生产经验------数据去重

数据传递语义

  • 至少一次(At Least Once)= ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2
  • 最多一次(At Most Once)= ACK级别设置为0
  • 总结
    At Least Once可以保证数据不丢失,但是不能保证数据不重复;
    At Most Once可以保证数据不重复,但是不能保证数据不丢失。
    精确一次(Exactly Once):对于一些非常重要的信息,比如和钱相关的数据,要求数据既不能重复也不丢失。Kafka 0.11版本以后,引入了一项重大特性:幂等性和事务。

幂等性

  • 1)幂等性原理
    幂等性就是指Producer不论向Broker发送多少次重复数据,Broker端都只会持久化一条,保证了不重复。
    精确一次(Exactly Once) = 幂等性 + 至少一次( ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2) 。
    重复数据的判断标准 :具有<PID, Partition, SeqNumber>相同主键的消息提交时,Broker只会持久化一条。其中PID是Kafka每次重启都会分配一个新的;Partition 表示分区号;Sequence Number是单调自增的。
    所以幂等性只能保证的是在单分区单会话内不重复。
  • 2)如何使用幂等性
    开启参数 enable.idempotence 默认为 true,false 关闭。

生产者事务

1)Kafka 事务原理
说明:开启事务,必须开启幂等性。

2)Kafka 的事务一共有如下 5 个 API

java 复制代码
// 1 初始化事务
void initTransactions();
// 2 开启事务
void beginTransaction() throws ProducerFencedException;
// 3 在事务内提交已经消费的偏移量(主要用于消费者)
void sendOffsetsToTransaction(Map<TopicPartition,OffsetAndMetadata> offsets, String consumerGroupId) throws ProducerFencedException;
// 4 提交事务
void commitTransaction() throws ProducerFencedException;
// 5 放弃事务(类似于回滚事务的操作)
void abortTransaction() throws ProducerFencedException;

3)单个 Producer,使用事务保证消息的仅一次发送

java 复制代码
package com.atguigu.kafka.producer;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;
public class CustomProducerTransactions {
	 public static void main(String[] args) throws InterruptedException {
		 // 1. 创建 kafka 生产者的配置对象
		 Properties properties = new Properties();
		 // 2. 给 kafka 配置对象添加配置信息
		 properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092");
		 // key,value 序列化
		 properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, 
		StringSerializer.class.getName());
		 
		 properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
		StringSerializer.class.getName());
		 // 设置事务 id(必须),事务 id 任意起名
		 properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "transaction_id_0");
		 // 3. 创建 kafka 生产者对象
		 KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);
		 // 初始化事务
		 kafkaProducer.initTransactions();
		 // 开启事务
		 kafkaProducer.beginTransaction();
		 try {
		 // 4. 调用 send 方法,发送消息
		 for (int i = 0; i < 5; i++) {
			 // 发送消息
			 kafkaProducer.send(new ProducerRecord<>("first", "jjm" + i));
		 }
		// int i = 1 / 0;
		 // 提交事务
		 kafkaProducer.commitTransaction();
		 } catch (Exception e) {
			 // 终止事务
			 kafkaProducer.abortTransaction();
		 } finally {
			 // 5. 关闭资源
			 kafkaProducer.close();
		 }
	 }
}

生产经验------数据有序

单分区内,有序(有条件的,详见下节);

多分区,分区与分区间无序;

生产经验------数据乱序

  • 1)kafka在1.x版本之前保证数据单分区有序,条件如下:
    max.in.flight.requests.per.connection=1(不需要考虑是否开启幂等性)
  • 2)kafka在1.x及以后版本保证数据单分区有序,条件如下:
    (2)开启幂等性
    max.in.flight.requests.per.connection需要设置小于等于5。
    (1)未开启幂等性
    max.in.flight.requests.per.connection需要设置为1。
    原因说明:因为在kafka1.x以后,启用幂等后,kafka服务端会缓producer发来的最近5个request的元数据,故无论如何,都可以保证最近5个request的数据都是有序的

Kafka Broker

Kafka Broker 工作流程

Zookeeper 存储的 Kafka 信息

(1)启动 Zookeeper 客户端。

sh 复制代码
[jjm@hadoop102 zookeeper-3.5.7]$ bin/zkCli.sh

(2)通过 ls 命令可以查看 kafka 相关信息。

sh 复制代码
[zk: localhost:2181(CONNECTED) 2] ls /kafka

Zookeeper中存储的Kafka 信息

Kafka Broker 总体工作流程

  • 1)模拟 Kafka 上下线,Zookeeper 中数据变化
    (1)查看/kafka/brokers/ids 路径上的节点。
sh 复制代码
[zk: localhost:2181(CONNECTED) 2] ls /kafka/brokers/ids
[0, 1, 2]

(2)查看/kafka/controller 路径上的数据。

sh 复制代码
[zk: localhost:2181(CONNECTED) 15] get /kafka/controller
{"version":1,"brokerid":0,"timestamp":"1637292471777"}

(3)查看/kafka/brokers/topics/first/partitions/0/state 路径上的数据。

sh 复制代码
[zk: localhost:2181(CONNECTED) 16] get /kafka/brokers/topics/first/partitions/0/state
{"controller_epoch":24,"leader":0,"version":1,"leader_epoch":18,"isr":[0,1,2]}

(4)停止 hadoop104 上的 kafka。

sh 复制代码
[jjm@hadoop104 kafka]$ bin/kafka-server-stop.sh

(5)再次查看/kafka/brokers/ids 路径上的节点。

sh 复制代码
[zk: localhost:2181(CONNECTED) 3] ls /kafka/brokers/ids
[0, 1]

(6)再次查看/kafka/controller 路径上的数据。

sh 复制代码
[zk: localhost:2181(CONNECTED) 15] get /kafka/controller
{"version":1,"brokerid":0,"timestamp":"1637292471777"}

(7)再次查看/kafka/brokers/topics/first/partitions/0/state 路径上的数据。

sh 复制代码
[zk: localhost:2181(CONNECTED) 16] get /kafka/brokers/topics/first/partitions/0/state
{"controller_epoch":24,"leader":0,"version":1,"leader_epoch":18,"isr":[0,1]}

(8)启动 hadoop104 上的 kafka。

sh 复制代码
[atguigu@hadoop104 kafka]$ bin/kafka-server-start.sh -daemon ./config/server.properties

(9)再次观察(1)、(2)、(3)步骤中的内容。

Broker 重要参数

参数名称 描述
replica.lag.time.max.ms ISR 中,如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR。该时间阈值,默认 30s
auto.leader.rebalance.enable 默认是 true。 自动 Leader Partition 平衡。
leader.imbalance.per.broker.percentage 默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值,控制器会触发 leader 的平衡。
leader.imbalance.check.interval.seconds 默认值 300 秒。检查 leader 负载是否平衡的间隔时间。
log.segment.bytes Kafka 中 log 日志是分成一块块存储的,此配置是指 log 日志划分 成块的大小,默认值 1G。
log.index.interval.bytes 默认 4kb,kafka 里面每当写入了 4kb 大小的日志(.log),然后就往 index 文件里面记录一个索引。
log.retention.hours Kafka 中数据保存的时间,默认 7 天
log.retention.minutes Kafka 中数据保存的时间,分钟级别,默认关闭
log.retention.ms Kafka 中数据保存的时间,毫秒级别,默认关闭
log.retention.check.interval.ms 检查数据是否保存超时的间隔,默认是 5 分钟
log.retention.bytes 默认等于-1,表示无穷大。超过设置的所有日志总大小,删除最早的 segment。
log.cleanup.policy 默认是 delete,表示所有数据启用删除策略;如果设置值为 compact,表示所有数据启用压缩策略。
num.io.threads 默认是 8。负责写磁盘的线程数。整个参数值要占总核数的 50%。
num.replica.fetchers 副本拉取线程数,这个参数占总核数的 50%的 1/3
num.network.threads 默认是 3。数据传输线程数,这个参数占总核数的50%的 2/3 。
log.flush.interval.messages 强制页缓存刷写到磁盘的条数,默认是 long 的最大值,9223372036854775807。一般不建议修改,交给系统自己管理。
log.flush.interval.ms 每隔多久,刷数据到磁盘,默认是 null。一般不建议修改,交给系统自己管理。

Kafka 副本

副本基本信息

(1)Kafka 副本作用:提高数据可靠性。

(2)Kafka 默认副本 1 个,生产环境一般配置为 2 个,保证数据可靠性;太多副本会增加磁盘存储空间,增加网络上数据传输,降低效率。

(3)Kafka 中副本分为:Leader 和 Follower。Kafka 生产者只会把数据发往 Leader,然后 Follower 找 Leader 进行同步数据。

(4)Kafka 分区中的所有副本统称为 AR(Assigned Repllicas)。

AR = ISR + OSR

ISR,表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms参数设定,默认 30s 。Leader 发生故障之后,就会从 ISR 中选举新的 Leader。
OSR,表示 Follower 与 Leader 副本同步时,延迟过多的副本。

Leader 选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader,负责管理集群broker 的上下线,所有 topic 的分区副本分配和 Leader 选举等工作。
Controller 的信息同步工作是依赖于 Zookeeper 的。
Leader选举流程

Leader 和 Follower 故障处理细节

  • Follower故障处理细节
    LEO(Log End Offset) :每个副本的最后一个offset,LEO其实就是最新的offset + 1。
    HW(High Watermark) :所有副本中最小的LEO 。

    1)Follower故障
    (1) Follower发生故障后会被临时踢出ISR
    (2) 这个期间Leader和Follower继续接收数据
    (3)待该Follower恢复后,Follower会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向Leader进行同步。
    (4)等该Follower的LEO大于等于该Partition的HW,即Follower追上Leader之后,就可以重新加入ISR了。
  • Leader故障处理细节

    2)Leader故障
    (1) Leader发生故障之后,会从ISR中选出一个新的Leader
    (2)为保证多个副本之间的数据一致性,其余的Follower会先将各自的log文件高于HW的部分截掉,然后从新的Leader同步数据。
    注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。

生产经验------Leader Partition 负载平衡

Leader Partition自动平衡

正常情况下,Kafka本身会自动把Leader Partition均匀分散在各个机器上,来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机,会导致Leader Partition过于集中在其他少部分几台broker上,这会导致少数几台broker的读写请求压力过高,其他宕机的broker重启之后都是follower partition,读写请求很低,造成集群负载不均衡。

  • auto.leader.rebalance.enable,默认是true。自动Leader Partition 平衡
  • leader.imbalance.per.broker.percentage,默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值,控制器会触发leader的平衡。
  • leader.imbalance.check.interval.seconds,默认值300秒。检查leader负载是否平衡的间隔时间。
    下面拿一个主题举例说明,假设集群只有一个主题如下图所示:

    针对broker0节点,分区2的AR优先副本是0节点,但是0节点却不是Leader节点,所以不平衡数加1,AR副本总数是4
    所以broker0节点不平衡率为1/4>10%,需要再平衡。
    broker2和broker3节点和broker0不平衡率一样,需要再平衡。
    Broker1的不平衡数为0,不需要再平衡
参数名称 描述
auto.leader.rebalance.enable 默认是 true 。 自动 Leader Partition 平衡。生产环境中 ,leader 重选举的代价比较大,可能会带来性能影响,建议设置为 false 关闭
leader.imbalance.per.broker.percentage 默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值,控制器会触发 leader 的平衡。
leader.imbalance.check.interval.seconds 默认值 300 秒。检查 leader 负载是否平衡的间隔时间。

生产经验------增加副本因子

在生产环境当中,由于某个主题的重要等级需要提升,我们考虑增加副本。副本数的增加需要先制定计划,然后根据计划执行。

1)创建 topic

sh 复制代码
[jjm@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server 
hadoop102:9092 --create --partitions 3 --replication-factor 1 --topic four

2)手动增加副本存储

(1)创建副本存储计划(所有副本都指定存储在 broker0、broker1、broker2 中)。

sh 复制代码
[jjm@hadoop102 kafka]$ vim increase-replication-factor.json

输入如下内容:

sh 复制代码
{"version":1,"partitions":[{"topic":"four","partition":0,"replicas":[0,1,2]},{"topic":"four","partition":1,"replicas":[0,1,2]},{"topic":"four","partition":2,"replicas":[0,1,2]}]}

(2)执行副本存储计划。

sh 复制代码
[jjm@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute

文件存储

文件存储机制

  • 1)Topic 数据的存储机制
    Topic是逻辑上的概念,而partition是物理上的概念,每个partition对应于一个log文件 ,该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端,为防止log文件过大导致数据定位效率低下,Kafka采取了分片和索引机制 ,将每个partition分为多个segment。每个segment包括:".index"文件、".log"文件和.timeindex等文件 。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号,例如:first-0
  • 2)思考:Topic 数据到底存储在什么位置?
    (1)启动生产者,并发送消息。
sh 复制代码
[jjm@hadoop102 kafka]$ bin/kafka-console-producer.sh --
bootstrap-server hadoop102:9092 --topic first
>hello world

(2)查看 hadoop102(或者 hadoop103、hadoop104)的/opt/module/kafka/datas/first-1(first-0、first-2)路径上的文件。

sh 复制代码
[jjm@hadoop104 first-1]$ ls
00000000000000000092.index
00000000000000000092.log
00000000000000000092.snapshot
00000000000000000092.timeindex
leader-epoch-checkpoint
partition.metadata
  • 3)index 文件和 log 文件详解

    说明:日志存储参数配置
参数 描述
log.segment.bytes Kafka 中 log 日志是分成一块块存储的,此配置是指 log 日志划分成块的大小,默认值 1G
log.index.interval.bytes 默认 4kb,kafka 里面每当写入了 4kb 大小的日志(.log),然后就往 index 文件里面记录一个索引。 稀疏索引。

文件清理策略

Kafka 中默认的日志保存时间为 7 天,可以通过调整如下参数修改保存时间。

  • log.retention.hours,最低优先级小时,默认 7 天。
  • log.retention.minutes,分钟。
  • log.retention.ms,最高优先级毫秒。
  • log.retention.check.interval.ms,负责设置检查周期,默认 5 分钟。
    那么日志一旦超过了设置的时间,怎么处理呢?
    Kafka 中提供的日志清理策略有 delete 和 compact 两种
    1)delete 日志删除:将过期数据删除
    log.cleanup.policy = delete 所有数据启用删除策略
    (1)基于时间默认打开 。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
    (2)基于大小:默认关闭 。超过设置的所有日志总大小,删除最早的 segment。
    log.retention.bytes,默认等于-1,表示无穷大。
    思考:如果一个 segment 中有一部分数据过期,一部分没有过期,怎么处理?
    2)compact 日志压缩
    compact日志压缩:对于相同key的不同value值,只保留最后一个版本
    log.cleanup.policy = compact 所有数据启用压缩策略

    压缩后的offset可能是不连续的,比如上图中没有6,当从这些offset消费消息时,将会拿到比这个offset大的offset对应的消息,实际上会拿到offset为7的消息,并从这个位置开始消费。
    这种策略只适合特殊场景,比如消息的key是用户ID,value是用户的资料,通过这种压缩策略,整个消息集里就保存了所有用户最新的资料。

高效读写数据

1)Kafka 本身是分布式集群,可以采用分区技术,并行度高
2)读数据采用稀疏索引,可以快速定位要消费的数据
3)顺序写磁盘

Kafka 的 producer 生产数据,要写入到 log 文件中,写的过程是一直追加到文件末端,为顺序写。官网有数据表明,同样的磁盘,顺序写能到 600M/s,而随机写只有 100K/s。这与磁盘的机械机构有关,顺序写之所以快,是因为其省去了大量磁头寻址的时间。
4)页缓存 + 零拷贝技术
零拷贝 :Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据,所以就不用走应用层,传输效率高。
PageCache页缓存:Kafka重度依赖底层操作系统提供的PageCache功 能。当上层有写操作时,操作系统只是将数据写入PageCache。当读操作发生时,先从PageCache中查找,如果找不到,再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。

参数 描述
log.flush.interval.messages 强制页缓存刷写到磁盘的条数,默认是 long 的最大值,9223372036854775807。一般不建议修改,交给系统自己管理。
log.flush.interval.ms 每隔多久,刷数据到磁盘,默认是 null。一般不建议修改,交给系统自己管理。

Kafka 消费者

Kafka 消费方式

  • pull(拉)模 式:
    consumer采用从broker中主动拉取数据。Kafka采用这种方式。
  • push(推)模式:
    Kafka没有采用这种方式,因为由broker决定消息发送速率,很难适应所有消费者的消费速率。例如推送的速度是50m/s,Consumer1、Consumer2就来不及处理消息。

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

Kafka 消费者工作流程

消费者总体工作流程

消费者组原理

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

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


    消费者组初始化流程

    消费者组详细消费流程

消费者重要参数

参数名称 描述
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 (broker config)or max.message.bytes (topic config)影响。
max.poll.records 一次 poll 拉取数据返回消息的最大条数,默认是 500 条

消费者 API

独立消费者案例(订阅主题)

  • 1)需求:
    创建一个独立消费者,消费 first 主题中数据。
    注意:在消费者 API 代码中必须配置消费者组 id。命令行启动消费者不填写消费者组id 会被自动填写随机的消费者组 id。
  • 2)实现步骤
    (1)创建包名:com.jjm.kafka.consumer
    (2)编写代码
java 复制代码
package com.jjm.kafka.consumer;
import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import java.time.Duration;
import java.util.ArrayList;
import java.util.Properties;
public class CustomConsumer {
	public static void main(String[] args) {
		// 1.创建消费者的配置对象
		Properties properties = new Properties();
		// 2.给消费者配置对象添加参数
		properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
		// 配置序列化 必须
		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<String> topics = new ArrayList<>();
		topics.add("first");
		kafkaConsumer.subscribe(topics);
		// 拉取数据打印
		while (true) {
			// 设置 1s 中消费一批数据
			ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
			// 打印消费到的数据
			for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
				System.out.println(consumerRecord);
			}
		}
	}
}
  • 3)测试
    (1)在 IDEA 中执行消费者程序。
    (2)在 Kafka 集群控制台,创建 Kafka 生产者,并输入数据。
sh 复制代码
[jjm@hadoop102 kafka]$ bin/kafka-console-producer.sh --bootstrap-server hadoop102:9092 --topic first
>hello

(3)在 IDEA 控制台观察接收到的数据。

sh 复制代码
ConsumerRecord(topic = first, partition = 1, leaderEpoch = 3, offset = 0, CreateTime = 1629160841112, serialized key size = -1, serialized value size = 5, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = hello)

生产经验------分区的分配以及再平衡

1、一个consumer group中有多个consumer组成,一个 topic有多个partition组成,现在的问题是,到底由哪个consumer来消费哪个partition的数据。

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

Range 以及再平衡

  • 1)Range 分区策略原理

    Range 是对每个 topic 而言的。首先对同一个 topic 里面的分区按照序号进行排序,并
    对消费者按照字母顺序进行排序。
    假如现在有 7 个分区,3 个消费者,排序后的分区将会是0,1,2,3,4,5,6;消费者排序完之后将会是C0,C1,C2。
    通过 partitions数/consumer数 来决定每个消费者应该消费几个分区。如果除不尽,那么前面几个消费者将会多消费 1 个分区
    例如,7/3 = 2 余 1 ,除不尽,那么 消费者 C0 便会多消费 1 个分区。 8/3=2余2,除不尽,那么C0和C1分别多消费一个。
    注意 :如果只是针对 1 个 topic 而言,C0消费者多消费1个分区影响不是很大。但是如果有 N 多个 topic,那么针对每个 topic,消费者 C0都将多消费 1 个分区,topic越多,C0消费的分区会比其他消费者明显多消费 N 个分区。
    容易产生数据倾斜!
  • 2)Range 分区分配再平衡案例
    (1)停止掉 0 号消费者,快速重新发送消息观看结果(45s 以内,越快越好)。
    1 号消费者:消费到 3、4 号分区数据。
    2 号消费者:消费到 5、6 号分区数据。
    0 号消费者的任务会整体被分配到 1 号消费者或者 2 号消费者。
    说明:0 号消费者挂掉后,消费者组需要按照超时时间 45s 来判断它是否退出,所以需要等待,时间到了 45s 后,判断它真的退出就会把任务分配给其他 broker 执行。
    (2)再次重新发送消息观看结果(45s 以后)。
    1 号消费者:消费到 0、1、2、3 号分区数据。
    2 号消费者:消费到 4、5、6 号分区数据。
    说明:消费者 0 已经被踢出消费者组,所以重新按照 range 方式分配。

RoundRobin 以及再平衡

  • 1)RoundRobin 分区策略原理

    RoundRobin 针对集群中所有Topic而言
    RoundRobin 轮询分区策略,是把所有的 partition 和所有的consumer 都列出来,然后按照 hashcode 进行排序,最后通过轮询算法来分配 partition 给到各个消费者。
  • 2)RoundRobin 分区分配再平衡案例
    (1)停止掉 0 号消费者,快速重新发送消息观看结果(45s 以内,越快越好)。
    1 号消费者:消费到 2、5 号分区数据
    2 号消费者:消费到 4、1 号分区数据
    0 号消费者的任务会按照 RoundRobin 的方式,把数据轮询分成 0 、6 和 3 号分区数据,分别由 1 号消费者或者 2 号消费者消费。
    说明:0 号消费者挂掉后,消费者组需要按照超时时间 45s 来判断它是否退出,所以需要等待,时间到了 45s 后,判断它真的退出就会把任务分配给其他 broker 执行。
    (2)再次重新发送消息观看结果(45s 以后)。
    1 号消费者:消费到 0、2、4、6 号分区数据
    2 号消费者:消费到 1、3、5 号分区数据
    说明:消费者 0 已经被踢出消费者组,所以重新按照 RoundRobin 方式分配。

Sticky 以及再平衡

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

粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略,首先会尽量均衡的放置分区

到消费者上面,在出现同一消费者组内消费者出现问题的时候,会尽量保持原有分配的分区不变化。

1)Sticky 分区分配再平衡案例

(1)停止掉 0 号消费者,快速重新发送消息观看结果(45s 以内,越快越好)。

1 号消费者:消费到 2、5、3 号分区数据。

2 号消费者:消费到 4、6 号分区数据。

0 号消费者的任务会按照粘性规则,尽可能均衡的随机分成 0 和 1 号分区数据,分别

由 1 号消费者或者 2 号消费者消费。

说明:0 号消费者挂掉后,消费者组需要按照超时时间 45s 来判断它是否退出,所以需要等待,时间到了 45s 后,判断它真的退出就会把任务分配给其他 broker 执行。

(2)再次重新发送消息观看结果(45s 以后)。

1 号消费者:消费到 2、3、5 号分区数据。

2 号消费者:消费到 0、1、4、6 号分区数据。

说明:消费者 0 已经被踢出消费者组,所以重新按照粘性方式分配。

offset 位移

offset 的默认维护位置

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

自动提交 offset

为了使我们能够专注于自己的业务逻辑,Kafka提供了自动提交offset的功能。

自动提交offset的相关参数:

  • enable.auto.commit:是否开启自动提交offset功能,默认是true
  • auto.commit.interval.ms:自动提交offset的时间间隔,默认是5s

手动提交 offset

虽然自动提交offset十分简单便利,但由于其是基于时间提交的,开发人员难以把握offset提交的时机。因此Kafka还提供了手动提交offset的API。

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

  • commitSync(同步提交):必须等待offset提交完毕,再去消费下一批数据。
  • commitAsync(异步提交) :发送完提交offset请求后,就开始消费下一批数据了。

指定 Offset 消费

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

当 Kafka 中没有初始偏移量(消费者组第一次消费)或服务器上不再存在当前偏移量

时(例如该数据已被删除),该怎么办?

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

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

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

指定时间消费

需求:在生产环境中,会遇到最近消费的几个小时数据异常,想重新按照时间消费。

例如要求按照时间消费前一天的数据,怎么处理?

操作步骤:

java 复制代码
package com.atguigu.kafka.consumer;
import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.serialization.StringDeserializer;
import java.time.Duration;
import java.util.*;
public class CustomConsumerForTime {
	 public static void main(String[] args) {
		 // 0 配置信息
		 Properties properties = new Properties();
		 // 连接
		 properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
		 // key value 反序列化
		 
		 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, "test2");
		 // 1 创建一个消费者
		 KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
		 // 2 订阅一个主题
		 ArrayList<String> topics = new ArrayList<>();
		 topics.add("first");
		 kafkaConsumer.subscribe(topics);
		 Set<TopicPartition> assignment = new HashSet<>();
		 while (assignment.size() == 0) {
			 kafkaConsumer.poll(Duration.ofSeconds(1));
			 // 获取消费者分区分配信息(有了分区分配信息才能开始消费)
			 assignment = kafkaConsumer.assignment();
		 }
		 HashMap<TopicPartition, Long> timestampToSearch = new HashMap<>();
		 // 封装集合存储,每个分区对应一天前的数据
		 for (TopicPartition topicPartition : assignment) {
			 timestampToSearch.put(topicPartition, System.currentTimeMillis() - 1 * 24 * 3600 * 1000);
		 }
		 // 获取从 1 天前开始消费的每个分区的 offset
		 Map<TopicPartition, OffsetAndTimestamp> offsets = kafkaConsumer.offsetsForTimes(timestampToSearch);
		 // 遍历每个分区,对每个分区设置消费时间。
		 for (TopicPartition topicPartition : assignment) {
			 OffsetAndTimestamp offsetAndTimestamp = offsets.get(topicPartition);
			 // 根据时间指定开始消费的位置
			 if (offsetAndTimestamp != null){
				 kafkaConsumer.seek(topicPartition, offsetAndTimestamp.offset());
			 }
		 }
		 // 3 消费该主题数据
		 while (true) {
			 ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
			 for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
			 	System.out.println(consumerRecord);
			 }
		 }
	 }
}

漏消费和重复消费

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

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

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

思考:怎么能做到既不漏消费也不重复消费呢?详看消费者事务。

生产经验------消费者事务

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

生产经验------数据积压(消费者如何提高吞吐量)

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

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

参数名称 描述
fetch.max.bytes 默认 Default: 52428800(50 m)。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值(50m)仍然可以拉取回来这批数据,因此,这不是一个绝对最大值。一批次的大小受 message.max.bytes (broker config)or max.message.bytes (topic config)影响。
max.poll.records 一次 poll 拉取数据返回消息的最大条数,默认是 500 条
相关推荐
云云3212 小时前
怎么通过亚矩阵云手机实现营销?
大数据·服务器·安全·智能手机·矩阵
新加坡内哥谈技术2 小时前
苏黎世联邦理工学院与加州大学伯克利分校推出MaxInfoRL:平衡内在与外在探索的全新强化学习框架
大数据·人工智能·语言模型
Data-Miner3 小时前
经典案例PPT | 大型水果连锁集团新零售数字化建设方案
大数据·big data
lovelin+v175030409663 小时前
安全性升级:API接口在零信任架构下的安全防护策略
大数据·数据库·人工智能·爬虫·数据分析
道一云黑板报3 小时前
Flink集群批作业实践:七析BI批作业执行
大数据·分布式·数据分析·flink·kubernetes
qq_5470261793 小时前
Kafka 常见问题
kafka
core5123 小时前
flink sink kafka
flink·kafka·sink
节点。csn3 小时前
flink集群搭建 详细教程
大数据·服务器·flink
数据爬坡ing4 小时前
小白考研历程:跌跌撞撞,起起伏伏,五个月备战历程!!!
大数据·笔记·考研·数据分析
云云3214 小时前
云手机方案全解析
大数据·服务器·安全·智能手机·矩阵