Kafka高频面试题总结

目录

 

1.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)又代表什么?

2.Kafka中的HW、LEO等分别代表什么?

3.Kafka中是怎么体现消息顺序性的?

4.Kafka中的分区器、序列化器、拦截器是否了解?它们之间的处理顺序是什么?

5.Kafka生产者客户端使用了几个线程来处理?分别是什么?

6.“消费组中的消费者个数如果超过topic的分区,那么就会有消费者消费不到数据”这句话是否正确?

7.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

8.有哪些情形会造成重复消费?

9.那些情景会造成消息漏消费?

10.当你使用kafka-topics.sh创建(删除)了一个topic之后,Kafka背后会执行什么逻辑?

11.topic的分区数可不可以增加?如果可以怎么增加?如果不可以,那又是为什么?

12.topic的分区数可不可以减少?如果可以怎么减少?如果不可以,那又是为什么?

13.Kafka有内部的topic吗?如果有是什么?有什么所用?

14.Kafka分区分配的概念?

15.简述Kafka的日志目录结构?

16.如果我指定了一个offset,Kafka Controller怎么查找到对应的消息?

17.聊一聊Kafka Controller的作用?

18.Kafka中有那些地方需要选举?这些地方的选举策略又有哪些?

19.失效副本是指什么?有那些应对措施?

20.Kafka的哪些设计让它有如此高的性能?

21.Kafka的用途有哪些?使用场景如何?

22.聊一聊你对Kafka的Log Retention的理解

23.为什么选择Kafka?

24.KafkaConsumer是非线程安全的,那么怎么样实现多线程消费?

25.简述消费者与消费组之间的关系 

26.创建topic时如何选择合适的分区数?

27.优先副本是什么?它有什么特殊的作用?

28.kafka过期数据清理?

29.Kafka中的幂等是怎么实现的

Kafka的入门相关知识点:


1.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)又代表什么?

ISR(InSyncRepli):内部副本同步队列,这是副本列表的一个子集,它当前是活动的,并被提交给leader。“leader”是负责给定分区的所有读写操作的节点。每个节点将是分区中随机选择的一部分的leader,“replicas”是复制这个分区的日志的节点列表,不管它们是主节点还是活动节点。

OSR(OutSyncRepli):外部副本同步队列

AR(AllRepli):所有副本

2.Kafka中的HW、LEO等分别代表什么?

    LEO:每个副本的最后条消息的offset

    HW:一个分区中所有副本最小的offset

3.Kafka中是怎么体现消息顺序性的?

每个分区内,每条消息都有一个offset,故只能保证分区内有序。

4.Kafka中的分区器、序列化器、拦截器是否了解?它们之间的处理顺序是什么?

Kafka通过生产者KafkaProducer的send()方法将消息发送到broker中,但在发送过程中需要经过拦截器(Interceptor)、序列化器(Serializer)和分区器(Partitioner)的一系列作用之后才能被真正地发往broker。消息在经过序列化后需要确定它发往的分区,如果消息ProducerRecord中指定了partition字段,那么就不需要分区器的作用,因为partition代表的就是所要发往的分区号

 拦截器 -> 序列化器 -> 分区器

5.Kafka生产者客户端使用了几个线程来处理?分别是什么?

 

整个生产者客户端主要有两个线程,主线程以及Sender线程。Producer在主线程中产生消息,然后通过拦截器,序列化器,分区器之后缓存到消息累加器RecordAccumulator中。Sender线程从RecordAccumulator中获取消息并发送到kafka中。

6.“消费组中的消费者个数如果超过topic的分区,那么就会有消费者消费不到数据”这句话是否正确?

 正确

7.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

 offset+1

8.有哪些情形会造成重复消费?

kafka的重复消费问题原因在于,已经消费了数据,但是offset没来得及提交(比如Kafka没有或者不知道该数据已经被消费)。

9.那些情景会造成消息漏消费?

先提交offset,后消费,有可能造成数据的重复

10.当你使用kafka-topics.sh创建(删除)了一个topic之后,Kafka背后会执行什么逻辑?

    1)会在zookeeper中的/brokers/topics节点下创建一个新的topic节点,如:/brokers/topics/first

    2)触发Controller的监听程序

    3)kafka Controller 负责topic的创建工作,并更新metadata cache

11.topic的分区数可不可以增加?如果可以怎么增加?如果不可以,那又是为什么?

可以增加

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3

12.topic的分区数可不可以减少?如果可以怎么减少?如果不可以,那又是为什么?

不可以减少,现有的分区数据难以处理。

13.Kafka有内部的topic吗?如果有是什么?有什么所用?

有 

__consumer_offsets 

保存消费者offset

14.Kafka分区分配的概念?

一个topic多个分区,一个消费者组多个消费者,故需要将分区分配个消费者(roundrobin、range)

  • 采用RoundRobin是面向组的,可能导致的问题是,同一个组里面的不同的消费者可以订阅不同的主题,因为是采用轮询的策略,这样配置会导致无效
  • 考虑range是面向主题的,这种策略的问题是可能会导致负载不均。

15.简述Kafka的日志目录结构?

 每个partition一个文件夹,包含四类文件.index .log .timeindex leader-epoch-checkpoint

.index .log .timeindex 三个文件成对出现 前缀为上一个segment的最后一个消息的偏移

16.如果我指定了一个offset,Kafka Controller怎么查找到对应的消息?

  • 通过文件名前缀数字x找到该绝对offset 对应消息所在文件
  • offset-x为在文件中的相对偏移
  • 通过index文件中记录的索引找到最近的消息的位置
  • 从最近位置开始逐条寻找

17.聊一聊Kafka Controller的作用?

   负责管理集群broker的上下线,所有topic的分区副本分配和leader选举等工作。

18.Kafka中有那些地方需要选举?这些地方的选举策略又有哪些?

 partition leader(ISR),controller(先到先得)

19.失效副本是指什么?有那些应对措施?

不能及时与leader同步

暂时踢出ISR,等其追上leader之后再重新加入

20.Kafka的哪些设计让它有如此高的性能?

分区,顺序写磁盘,0-copy

21.Kafka的用途有哪些?使用场景如何?

异步处理、日常系统解耦、削峰、提速、广播

如果再说具体一点例如:消息,网站活动追踪,监测指标,日志聚合,流处理,事件采集,提交日志等

22.聊一聊你对Kafka的Log Retention的理解

kafka留存策略包括 删除和压缩两种

  • 删除: 根据时间和大小两个方式进行删除 大小是整个partition日志文件的大小,超过的会从老到新依次删除 时间指日志文件中的最大时间戳而非文件的最后修改时间
  • 压缩: 相同key的value只保存一个 压缩过的是clean 未压缩的dirty 压缩之后的偏移量不连续 未压缩时连续

23.为什么选择Kafka?

吞吐量高,大数据消息系统唯一选择。

24.KafkaConsumer是非线程安全的,那么怎么样实现多线程消费?

  • 每个线程维护一个KafkaConsumer
  • 维护一个或多个KafkaConsumer,同时维护多个事件处理线程(worker thread) 

25.简述消费者与消费组之间的关系 

消费者从属与消费组,消费偏移以消费组为单位。每个消费组可以独立消费主题的所有数据,同一消费组内消费者共同消费主题数据,每个分区只能被同一消费组内一个消费者消费。

26.创建topic时如何选择合适的分区数?

  1. 创建一个只有1个分区的topic
  2. 测试这个topic的producer吞吐量和consumer吞吐量。
  3. 假设他们的值分别是Tp和Tc,单位可以是MB/s。
  4. 然后假设总的目标吞吐量是Tt,那么分区数=Tt / max(Tp,Tc)

27.优先副本是什么?它有什么特殊的作用?

优先副本 会是默认的leader副本 发生leader变化时重选举会优先选择优先副本作为leader

28.kafka过期数据清理?

日志清理保存的策略只有delete和compact两种

log.cleanup.policy=delete启用删除策略

log.cleanup.policy=compact启用压缩策略

29.Kafka中的幂等是怎么实现的

Producer的幂等性指的是当发送同一条消息时,数据在Server端只会被持久化一次,数据不丟不重,但是这里的幂等性是有条件的:

1)只能保证Producer在单个会话内不丟不重,如果Producer出现意外挂掉再重启是无法保证的(幂等性情况下,是无法获取之前的状态信息,因此是无法做到跨会话级别的不丢不重)。

2)幂等性不能跨多个Topic-Partition,只能保证单个Partition内的幂等性,当涉及多个 Topic-Partition时,这中间的状态并没有同步。

Kafka的入门相关知识点:

https://blog.csdn.net/Poolweet_/article/details/109246515

猜你喜欢

转载自blog.csdn.net/Poolweet_/article/details/109312019