Kafka：整理的一些面试题

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

ISR：In-Sync Replicas 副本同步队列
AR：Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

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

LEO（Log End Offset）：每个副本的最后一个offset
HW（High Watermark）：所有副本的最小LEO

follower故障时：follower会被踢出isr，恢复后，follower读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步，等follower的LEO大于等于该partition的HW后，就可以重新加入isr。

leader故障时：leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的， 数据一致性， 其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。

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

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.

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

**分区器：**可以给消息指定传入分区
**序列化器：**将生产者消息序列化，可以被网络传输
**：**可以在消息传入Kafka前和producer回调函数返回前对消息进行简单的处理

5. Kafka 生产者客户端的整体结构是什么样子的？使用了几个线程来处理？分别是什么？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uUxlqKGQ-15861239914)(1586155090138.png)]

main线程负责：—>序列化器—>分区器
sender线程负责：将分区后的数据发送给对于分区

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

正确，这样会浪费资源。

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

offset+1

8.有哪些情形会造成重复消费？那些情景会造成消息漏消费 ？

重复消费：先处理数据，再提交offset
消息漏消费：先提交offset，再处理数据

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

消息的重复消费，即要解决消费时的幂等性。解决思路：

• 生产者生产数据时，添加一个全局唯一的id，处理时如果发现一个id已经被处理，那就忽略这条消息
• 如果消费操作是向数据库中插入数据，可以利用数据库的唯一键

生产时的幂等性如何解决？

9. 当你使用 kafka-topics.sh 创建（删除）了一个 topic 之后， Kafka 背后会执行什么逻辑？

• 会在 zookeeper 中的/brokers/topics 节点下创建一个新的 topic 节点，如：/brokers/topics/first
• 触发 Controller 的监听程序
• kafka Controller 负责 topic 的创建工作，并更新 metadata cache

10. topic 的分区数可不可以增加？可不可以减少？为什么？

分区数可以增加，不可以减少

按照Kafka现有的代码逻辑而言，此功能完全可以实现，不过也会使得代码的复杂度急剧增大。实现此功能需要考虑的因素很多，比如删除掉的分区中的消息该作何处理？如果随着分区一起消失则消息的可靠性得不到保障；如果需要保留则又需要考虑如何保留。直接存储到现有分区的尾部，消息的时