Kafka知识点整理
1. Kafka的用途有哪些？使用场景如何？
使用场景：用户活动跟踪、传递消息、收集应用程序和系统度量指标以及日志、日志聚合、流处理、数据中心。
2. 为Kafka选择硬件从哪些方面进行考虑？
磁盘吞吐量：机械硬盘或固态硬盘、磁盘特地的技术等；
磁盘容量：每天产生消息的容量以及消息保留时间；
内存：磁盘性能影响生产者，而内存影响消费者因为消费者读取的消息会直接存放在系统的页面缓存中。
网络：网络吞吐量决定了Kafka能够处理的最大数据流量；
CPU：Kafka对CPU的要求较低。
3. 如何考虑一个Kafka集群中需要多少Broker？
一个Kafka集群需要多少Broker取决与以下几个因素：首先，需要多少磁盘空间来保留数据，以及单个broker有多少可用空间。其次，要考虑集群处理请求的能力。
4. Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么
分区中所有的副本统称为AR，所有与Leader副本保持一定程度同步的副本统称ISR。与Leader同步滞后过多的副本统称OSR。Kafka在启动的时候会开启两个与ISR相关的定时任务，周期性的检测每个分区是否需要缩减其ISR集合。当检测到ISR集合中有失效副本时，就会收缩ISR集合。当Follower不断与Leader进行消息同步追赶上了Leader副本，判断标准是此副本的LEO是否小于Leader副本的HW。
5. Kafka中的HW、LEO、LSO、LW等分别代表什么？
HW俗称高水位它标识了一个特定的消息偏移量，消费者只能拉取到该Offt之前的消息。
LEO它标识了当前日志文件中下一条待写入消息的Offt。
LW俗称“低水位”，代表 AR 集合中最小的 logStartOfft 值。副本的拉取请求和删除消息请求都有可能促使 LW 的增长。
logStartOfft：一般情况下，日志文件的起始偏移量 logStartOfft 等于第一个日志分段的 baOfft，但这并不是绝对的，logStartOfft 的值可以通过 DeleteRecordsRequest 请求、日志的清理和截断等操作进行修改。
LSO特指LogStableOfft与Kafka的事务有关，isolation.level设置为read_committed消费者就会忽略事务未提交的消息，即只能消费到 LSO(LastStableOfft)的位置
6. Kafka中是怎么体现消息顺序性的？
Kafka无法确保整个topic中消息的顺序性，但可以保正单个分区内消息的顺序性。在Kafka中默认情况下不指定消息要发往的分区信息，相同key的消息会被发送到指定分区。
7. Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？
分区器的作用就是为消息分配分区。序列化器把ProducerRecord对象转换成字节数据组。
拦截器是在消息发送前做一些准备工作或发送回调前做一些定制化的工作。他们的处理顺序拦截器->序列化器->分区器
8. Kafka生产者客户端的整体结构是什么样子的？
整个生产者客户端由两个线程协调运行，这两个线程分别是主线程和发送线程。在主线程中由KafkaProducer创建消息，然后通过拦截器、序列化器和分区器的作用之后缓存到消息累加器中。Sender线程负责从消息累加器中获取消息并将其发送到Kafka中。
9. Kafka生产者客户端中使用了几个线程来处理？分别是什么？
整个生产者客户端由两个线程协调运行，这两个线程分别是主线程和发送线程。
10. Kafka的旧版Scala的消费者客户端的设计有什么缺陷？
11. “消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确？如果不正确，那么有没有什么hack的手段？
一般情况Kafka中消费者组中的每个消费者只能消费其订阅topic的一个分区数据，Kafka的
独立消费者只分配主题的某个或某几个分区数据。
12. 消费者提交消费位移时提交的是当前消费到的最新消息的offt还是offt+1?
消费者提交消费位移时提交的是offt+1
13. 有哪些情形会造成重复消费？
消费者消费后没有commit offt(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)
14. 那些情景下会造成消息漏消费？
消费者没有处理完消息 提交offt(自动提交偏移 未处理情况下程序异常结束)
15. KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？
1.在每个线程中新建一个KafkaConsumer；
2.单线程创建KafkaConsumer，多个处理线程处理消息（难点在于是否要考虑消息顺序性，offt的提交方式）
16. 简述消费者与消费组之间的关系
消费者从属于消费组，消费偏移以消费组为单位。每个消费组可以独立消费主题的所有数据，同一消费组内的消费者共同消费主题数据，每个分区只能被同一消费组内一个消费者消费。
17. 当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？
在Zookeeper中的/admin/delete_topics/路径下创建一个与待删除主题同名的节点，以此标记该主题为待删除状态。KafkaController会监听/admin/delete_topics/路径下的节点变化，当监听到有节点变化时就负责接下去的具体的删除工作。
18. topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？
Topic的分区数可以增加。通过kafka-topic.sh脚本的alert命令增加。Kafka-topic.sh –zookeeper localhost:2181 –alert –topic topic_demo –partitions 3
19. topic的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？
目前Kafka只支持增加分区数而不支持减少分区数。原因：会使得代码的复杂度急剧增大。实现此功能需要考虑的因素很多，比如删除掉的分区中的消息该作何处理？如果随着分区一起消失则消息的可靠性得不到保障；如果需要保留则又需要考虑如何保留。直接存储到现有分区的尾部，消息的时间戳就不会递增，如此对于Spark、Flink这类需要消息时间戳（事件时间）的组件将会受到影响；如果分散插入到现有的分区中，那么在消息量很大的时候，内部的数据复制会占用很大的资源，而且在复制期间，此主题的可用性又如何得到保障？与此同时，顺序性问题、事务性问题、以及分区和副本的状态机切换问题都是不得不面对的。反观这个功能的收益点却是很低，如果真的需要实现此类的功能，完全可以重新创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可。
20. 创建topic时如何选择合适的分区数？
创建topic时分区数的选择需要从某些角度做具体分析，根据实际的业务场景、软件条件、硬件条件和负载情况等做具体的考量。在创建完主题之后，虽然我们还是能够增加分区的个数，但是基于key计算的主题需要严谨对待。当生产者向Kafka中写入基于key的消息时，Kafka通过消息的key来计算出消息将要写入到哪个具体的分区中，这样具有相同key
的数据可以写入到同一个分区中。尤其对于与key高关联的应用，在创建主题时可以适当地多创建一些分区，以满足未来的需求。
先估算出主题的吞吐量和消费者吞吐量，可以用主题的吞吐量除以消费者吞吐量算出分区的个数。
21. Kafka目前有哪些内部topic，它们都有什么特征？各自的作用又是什么？
Kafka目前内部有__consumer_offts和__transaction_state两个主题，由Kafka自动创建和管理。__consumer_offts存储消费者位移信息，__transaction_state存储事务状态。
22. 优先副本是什么？它有什么特殊的作用？
23. Kafka有哪几处地方有分区分配的概念？简述大致的过程及原理
生产者分区分配：消息在发往broker之前是需要确定它所发往的分区的，如果消息ProducerRecord中指定了partition字段，那么就不需要分区器的作用，因为partition代表的就是所要发往的分区号。如果消息ProducerRecord中没有指定partition字段，那么就需要
依赖分区器，根据key这个字段来计算partition的值。分区器的作用就是为消息分配分区。如果key为null，那么消息将会以轮询的方式发往主题内的各个可用分区。
消费者分区分配：在Kafka的默认规则中，每一个分区只能被同一个消费组中的一个消费者消费。消费者的分区分配是指为消费组中的消费者分配所订阅主题中的分区。Kafka自身提供了三种策略，分别为RangeAssignor、RoundRobinAssignor以及StickyAssignor，其中RangeAssignor为默认的分区分配策略。
