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 312.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个分区的topic
- 测试这个topic的producer吞吐量和consumer吞吐量。
- 假设他们的值分别是Tp和Tc，单位可以是MB/s。
- 然后假设总的目标吞吐量是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