kafka知识点

最新推荐文章于 2024-06-13 10:21:36 发布

Java页大数据

最新推荐文章于 2024-06-13 10:21:36 发布

阅读量159

点赞数

分类专栏： kafka 文章标签： kafka

本文链接：https://blog.csdn.net/liguanhaoyonghu/article/details/114387406

版权

kafka 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

kafka

kafka定义：kafka是一个分布式的基于发布订阅模式的消息队列，应用于大数据实时领域
发布订阅模式（一对多，消费者消费数据之后不会清除消息）：消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅subscribe）消费该消息。topic的消息会被所有订阅者消费。

kafka基础架构组成

组成：生产者、消费者（消费者组）、broker（服务器）、zookeeper
producer生产者：消息生产者，就是向kafka broker发消息的客户端
consumer消费者：消息消费者，向kafka broker取（消费）消息的客户端
consumer Group：消费者组，由多个消费者组成。
- **消费者组组内每个消费者负责消费不同分区的数据，一个分区只能由组内一个消费者消费，不存在一个分区由多个消费者共同消费；**消费者组之间互不影响。消费者组是逻辑上的一个订阅者
broker：一台kafka服务器就是一个broker；一个集群由多个broker组成。一个broker可以容纳多个topic
topic：可以理解为一个队列，生产者和消费者面向的都是一个topic
partition：为了实现扩展性，一个topic可以分布到多个broker上，一个topic可以分为多个partition，每个partition是一个有序的队列；
replica：副本，为保证集群中的某个节点发送故障时，该节点的partition数据不丢失，且kafka仍能继续工作，kafka提供了副本机制：一个topic的每个分区都有若干个副本，包括一个leader和若干个follower
leader：每个分区多个副本的主，生产者发送数据的对象，以及消费者消费数据的对象都是leader
follower：每个分区多个副本的从，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower（在ISR里面）会成为新的leader。

kafka命令

topic：即在broker上操作，需要关联到zookeeper的地址，分区数、副本数

查看当前服务器的所有topic
- bin/kafka-topics.sh --zookeeper slave1:2181,slave2:2181,slave3:2181 --list
创建topic：
- bin/kafka-topics.sh --zookeeper slave1:2181,slave2:2181,slave3:2181 --create --replication-factor 3 --partitions 1 --topic topicname
删除topic：
- bin/kafka-topics.sh --zookeeper slave1:2181,slave2:2181,slave3:2181 --delete --topic topicname
- 仅仅只是被标记删除而已
查看topic详情
- bin/kafka-topics.sh --zookeeper slave1:2181,slave2:2181,slave3:2181 --describe --topic tmp
修改分区数（修改分区数只能增加）
- 为什么不能减少分区数：会导致数据丢失
- bin/kafka-topics.sh -zookeeper slave1:2181,slave2:2181,slave3:2181 --alter --topic tmp --partitions 4

生产者：即用到kafka-console-producer.sh，需要关联到broker集群(broker-list参数)

向topic发送消息
- bin/kafka-console-producer.sh --broker-list slave1:9092,slave3:9092,slave2:9092 --topic tmp

消费者：即用到kafka-console-consumer.sh，需要关联到broker集群发布的页面（–bootstrap-server参数）

消费消息
- bin/kafka-console-consumer.sh --bootstrap-server slave1:9092,slave2:9092,slave3:9092 --topic tmp

kafka工作流程及文件存储机制

kafka工作流程

kafka中消息是以topic进行分类的，生产者和消费者都是面向topic的
topic是逻辑上的概念，而partition是物理上的概念。
每个partition对应着一个log文件，该log文件中存储的就是producer生产者的生产数据。producer生产的数据会不断追加到log文件末端，且每条数据都由自己的offset。
消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，可以从上次的位置继续消费
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0q5beT6Q-1614914719386)(C:\Users\Thinkpad\AppData\Roaming\Typora\typora-user-images\1614408473284.png)]
防止log文件过大导致定位效率低下，kafka采用了分片和索引的机制
- 每个partition对应着一个log文件，一个log文件分为多个segment。每个segment对应着两个文件----index文件和log文件
  - segment下的文件位于一个文件夹下，该文件夹的命名规则：topic名称 + 分区序号。例如：first主题有三个分区，则其对应的文件夹为first-0,first-1,first-2
  - index和log文件以当前的segment的第一条消息的offset命名！
  - index文件存储大量的索引信息，log文件存储大量的数据。index文件中的元数据指向对应数据文件中的message的物理偏移量

kafka生产者

分区策略：
- 分区原因：
  - 方便在集群中扩展
  - 可以提高并发，kafka是以partition为单位进行读写的
- 分区原则：将数据封装为一个producerRecord对象（包含了主题名，数据[,分区号]）
- 分区类型：（3种）
  - 指明partition的情况下，直接将指明的值作为分区号进行生产消息
  - 没有指明partition，但有key的情况下，将key的hash值与topic的partition分区数进行取余，得到要发往消息的分区号。
  - 既没有指明partition也没有key的情况下，第一次调用时，随机生成一个整数（后面每次调用就在这个整数自增），将整数与topic的分区数取余，得到需要发往消息的分区号。（轮询算法）

数据可靠性保证：

为保证producer发送的数据，能可靠的到达指定的topic，topic的每一个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进入下一轮的发送，否则会重新发送数据
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-auxdKpnC-1614914719397)(C:\Users\Thinkpad\AppData\Roaming\Typora\typora-user-images\1614411148742.png)]
kafka选择了全部完成同步才发送ack的副本数据同步策略，原因如下
- 为了容忍n台节点的故障，该同步策略只需要n+1个副本即可。
- 虽然该策略的网络延迟比较高，但是网络延迟对kafka的影响较小

ISR：

问题抛出：kafka选择了全部完成同步才发送ack的同步策略，如果有一个follower可能因为故障，久久不能与leader同步，那么leader就要一致等下去，知道完成同步才能发送ack。那这个问题需要怎么解决？引入了ISR
leader维护了一个动态的 ISR，意为：和leader保持同步的follower集合
当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间没有向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。leader发生故障，就会从ISR中的follower选举出新的leader。

ack应答机制

acks参数配置

ack级别：
- 0：生产者不等待broker的ack，这是最低的延迟，broker一接收到消息还没有写入磁盘就已经返回了。当broker故障时可能丢失数据
- 1：生产者等待broker的ack，分区的leader落盘成功后返回ack。在follower同步成功之前，leader故障，将丢失数据
- -1：生产者等待broker的ack，分区的leader和follower全部落盘成功后才会返回ack。如果follower同步完成后，broker发送ack之前，leader故障，那么会导致数据重复

故障处理细节

针对于log文件中的HW和LEO
LEO（log end offset）:每个副本的最后一个offset；每个副本最大的offset
HW（high watermark）：所有副本中最小的LEO，指的是消费者能见到的最大的offset，ISR队列中最小的LEO
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AWkcTpfz-1614914719405)(C:\Users\Thinkpad\AppData\Roaming\Typora\typora-user-images\1614414342044.png)]

leader故障

leader故障后，会从ISR中选出一个新的leader；之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据（1.选出leader2.follower截掉高于hw的消息3.从新leader同步数据）
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复（这和ack的设置有关）

follower故障

follower故障后会被踢出ISR队列，待该follower恢复后，follower会读取本地磁盘记录上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader同步数据。等follower的LEO大于等于该分区的HW，就可以重新加入ISR了。（1.被提出ISR，2.恢复正常工作从磁盘读取上次记录的HW，将log文件截掉高于上次HW的消息，并向leader进行同步，3.follower的LEO大于等于分区的HW，即可进入到ISR）

exactly once语义

将ack设置为-1，保证不会丢失数据，即AtLeast Once语义。
将ack设置为0，保证数据只会被发送一次，即At Most Once语义
AtLeast Once只能保证数据不丢失，但不能保证数据不重复。
AtMost Once可以保证数据不重复，但不能保证数据不丢失。

幂等性

问题抛出：怎么实现Exactly Once语义呢？
- kafka0.11版本之前，在ack设置为-1，然后在下游消费者对数据进行全局去重（多个下游应用的情况下，每个都需要做全局去重，性能低下）
- 很简单，就是基于 Kafka 的 At-Least-Once 加上去重，把处理过的 record 记录下来，发现重复处理时就把它扔掉
0.11版本后，引入了幂等性特性。
幂等性：指生产者无论向server发送多少次重复数据，server只会持久化一条。
幂等性结合AtLeast Once语义，就构成了Exactly Once语义。即：AtLeast Once + 幂等性 = Exactly Once
启用幂等性：将producer的参数中enable.idompotence设置为true即可。
幂等性实现了将原来下游需要做的去重任务放在了数据上游
关于幂等性：
- 开启幂等性的producer在初始化的时候会被分配一个pid，发往同一个分区的消息会附带Sequence Number。broker端会对**<pid,partition,seqnumber>做缓存，当具有相同主键**的消息提交时，broker只会持久化一条。
但是kafka重启后，pid会发生变化，同时不同的partition分区也有不同主键，所以幂等性无法保证跨分区会话的Exactly Once

kafka消费者

消费方式：采取拉模式从broker中读取数据
- 根据consumer的消费能力以适当的速率消费消息
- 拉模式不足：如果kafka broker没有数据，消费者会陷入循环中，一直返回空数据！！！
  - 问题解决：消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间后再返回。这段时长即为timeout
为什么不用推模式：
- 推模式下，消息发送速率是由broker决定的，她的目标是尽可能以最快速度传递消息，但是这样容易造成consumer来不及处理消息。
- 典型的表现是：拒绝服务以及网络拥塞。

分区分配策略：

一个消费者组中有多个消费者，一个topic中有多个partition，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费
消费分配策略有两种
- roundrobin轮询模式：
  - 针对组内的所有成员来分发
  - 将消费者组订阅的所有主题的所有分区进行排序，并逐一分配给组内消费者。
  - 组内首个消费者可能会多消费一个分区的消息，消费者之间消费相差最多一个分区的消息
  - 弊端：只适合消费者组中所有消费者订阅的主题一致；不适合组内消费者组内消费者订阅的主题不一致
- range范围模式：（默认模式）
  - 针对单个主题，范围分发给消费者；按一个个主题来分配
  - 对一个主题而言，组内的首个消费者可能会消费会多出一个分区消息；如果有非常多的主题，那有可能导致组内的首个消费者频繁多消费一个分区的消息
  - 弊端：组内首个消费者消费的数据可能远超过组内其他消费者
触发消费的分区分配策略的情况：
- 消费者组内的消费者个数发生改变
- topic中的分区数发生改变

offset的维护（消费者维护）

offset由消费者组 + 分区 + 主题组成

consumer在消费过程中发生故障，待consumer恢复后，需要从故障前的位置开始消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费
- kafka0.9版本前，consumer默认将offset保存在zookeeper中，从0.9版本开始，consumer默认将offset保存到kafka一个内置的topic中，该topic为__consumer_offset.
- 0.11版本后，读取kafka的offset：bin/kafka-topics.sh --topic __consumer_offsets --zookeeper slave1:2181 --formatter “kafka.coordinator.group.GroupMetadataManager$OffsetsMessageFormatter” --consumer.config config/consumer.properties --from-beginning

消费者组案例

测试同一个消费者组的消费者，同一时刻只能有一个消费者消费

kafka高效读写数据

分区
顺序写磁盘；kafka的生产者生产数据，要写入log文件中，写的过程是一直追加到文件末端，为顺序写；顺序写比随机写快很多
零复制技术

zookeeper在kafka的作用

kafka集群中有一个broker会被选举为controller，负责管理集群broker的上下线，topic的分区副本分配和leader选举等工作。
controller的管理工作是依赖于zookeeper的。

kafka事务

kafka从0.11版本引入事务支持。事务可以保证kafka在exactly once语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。（幂等性+至少一次性语义 =不能跨分区跨会话）

producer事务

为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID（事务id），并将producer获得的pid和transaction ID绑定。这样当producer重启后就可以通过正在进行的事务id获得原来的pid。
为了管理事务，kafka引入了新的组件Transaction Coordinator。
- producer就是和Transcation Coordinator交互，从而获得Transcation ID对应的任务状态。
- Transcation Coordinator还负责将事务所有写入kafka的一个内部topic中。这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

kafka API

kafka的producer发送消息采用的是异步发送的方式。
在消息发送过程中，涉及到了两个线程----main线程和Sender线程，以及一个线程共享变量-----RecordAccumulator。
- main线程：将消息发送给RecordAccumlator
- Sender线程：不断从RecordAccumlator中拉取消息发送到kafka broker
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4LKdWE77-1614914719417)(C:\Users\Thinkpad\AppData\Roaming\Typora\typora-user-images\1614430937334.png)]

需要用到的类：

kafkaProducer：生产者对象，用来发送数据（producer.send）#send方法可以有回调函数也可以没有回调函数

for (int i = 0; i < 100; i++) {
 producer.send(new ProducerRecord<String, String>("first",
Integer.toString(i), Integer.toString(i)));
 }

ProducerConfig：获取kafka需要的一系列配置参数（这些都是producerconfig类的常量值）

Properties props = new Properties();
 //kafka 集群，broker-list
 props.put("bootstrap.servers", "hadoop102:9092");
 props.put("acks", "all");
 //重试次数
 props.put("retries", 1);
 //批次大小
 props.put("batch.size", 16384);
 //等待时间
 props.put("linger.ms", 1);
 //RecordAccumulator 缓冲区大小
 props.put("buffer.memory", 33554432);
 //序列化编码与反序列化编码
 props.put("key.serializer",
"org.apache.kafka.common.serialization.StringSerializer");
 props.put("value.serializer",
"org.apache.kafka.common.serialization.StringSerializer");

producerRecord：每条数据封装成一个ProducerRecord对象（消息发送哪个分区）#topic名，数据内容
- ```
new ProducerRecord<String, String>("first",
Integer.toString(i), Integer.toString(i)
```

consumer API

consumer消费数据时的可靠性是很容易保证的，因为数据在kafka中是持久化的，姑不用担心数据丢失问题
但是consumer需要实时记录自己消费消息的offset，以便出故障后可以从原来位置继续进行消费。因此offset的维护是consumer消费数据是必须考虑的问题

需要用到的类：

kafkaconsumer：创建一个消费者对象，用来消费数据（订阅主题subscribe）
- ```
consumer.subscribe(Arrays.asList("first"));
```

consumerconfig：获取所需的一系列配置参数（常量值）

Properties props = new Properties();
 props.put("bootstrap.servers", "hadoop102:9092");
 props.put("group.id", "test");
 props.put("enable.auto.commit", "true");
 props.put("auto.commit.interval.ms", "1000");
 props.put("key.deserializer",
"org.apache.kafka.common.serialization.StringDeserializer");
 props.put("value.deserializer",
"org.apache.kafka.common.serialization.StringDeserializer");

consumerRecord：每条数据都要被封装成一个consumerRecord对象

自动提交offset的相关参数：
- enable.auto.commit：是否开启自动提交offset的功能
- auto.commit.interval.ms:自动提交offset的时间间隔
手动提交offset：
- 手动提交 offset 的方法有两种：
  - 分别是 commitSync（同步提交）和 commitAsync（异步
    提交）。
  - 两者的相同点是：都会将本次 poll 的一批数据最高的偏移量提交；
  - 不同点是：
    - commitSync 阻塞当前线程，一直到提交成功，并且会自动失败重试（由不可控因素导致，也会出现提交失败）
    - commitAsync 则没有失败重试机制，故有可能提交失败。

拦截器

拦截器在0.10版本引入，用于实现客户端的定制化控制逻辑
自定义拦截器：
- 实现org.apache.kafka.clients.producer.ProducerInterceptor
- 实现方法：
  - configure（configs）：获取配置信息和初始化时调用
  - onsend（producerRecord）：该方法封装进kafkaproducer.send方法中，即它运行种子用户主线中。producer确保在消息被序列化以及计算分区前调用该方法。用户可以在该方法中对消息做任何操作，但最好保证不要修改消息所属的topic和分区，否则会影响目标分区的计算
  - onAcknowledgement（RecordMetadata，Exception）：该方法会在消息从RecordAccumlator成功发送到kafka broker之后，或者在发送过程中失败时调用。并且通常都是在producer回调逻辑触发之前。
    e（configs）：获取配置信息和初始化时调用
  - onsend（producerRecord）：该方法封装进kafkaproducer.send方法中，即它运行种子用户主线中。producer确保在消息被序列化以及计算分区前调用该方法。用户可以在该方法中对消息做任何操作，但最好保证不要修改消息所属的topic和分区，否则会影响目标分区的计算
  - onAcknowledgement（RecordMetadata，Exception）：该方法会在消息从RecordAccumlator成功发送到kafka broker之后，或者在发送过程中失败时调用。并且通常都是在producer回调逻辑触发之前。
  - close：关闭interceptor，主要用于执行一些资源清理工作

Java页大数据

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
kafka知识点

kafkakafka定义：kafka是一个分布式的基于发布订阅模式的消息队列，应用于大数据实时领域发布订阅模式（一对多，消费者消费数据之后不会清除消息）：消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅subscribe）消费该消息。topic的消息会被所有订阅者消费。kafka基础架构组成组成：生产者、消费者（消费者组）、broker（服务器）、zookeeperproducer生产者：消息生产者，就是向kafka broker发消息的客户端consumer消费者：
复制链接

扫一扫