【Kafka】面试题

1什么是Kafka？Kafka中有哪几个组件？

Kafka是分布式发布-订阅消息系统,是一个可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。
组件:
主题(Topic)：Kafka主题是一堆或一组消息。
生产者(Producer)：在Kafka，生产者发布通信以及向Kafka主题发布消息。
消费者(Consumer)：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。
经纪人(Brokers)：在管理主题中的消息存储时，我们使用Kafka Broker

2 Kafka为什么那么快？

1 Kafka的消息是保存或缓存在磁盘上的,一般认为在磁盘上读写数据是会降低性能的,
但是实际上，Kafka的特性之一就是高吞吐率。
2 Kafka也可以轻松支持每秒百万级的写入请求，超过了大部分的消息中间件，
这种特性也使得Kafka在日志处理等海量数据场景广泛应用。
3 写入数据
顺序写入,由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
4 读取数据
基于sendfile实现Zero Copy零拷技术减少拷贝次数,Batching of Messages 批量处理。
合并小的请求，然后以流的方式进行交互，直顶网络上限。

3 Kafka系统工具有哪些类型？

1. Kafka迁移工具：它有助于将代理从一个版本迁移到另一个版本。
2. Mirror Maker：Mirror Maker工具有助于将一个Kafka集群的镜像提供给另一个。
3. 消费者检查:对于指定的主题集和消费者组，它显示主题，分区，所有者。

4 Kafkal的message格式是什么？

一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成
header部分
由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。
body部分
由N个字节构成的一个消息体，包含了具体的key/value消息

5 Kafka的优点有那些？

1 高吞吐量：我们在Kafka中不需要任何大型硬件，因为它能够处理高速和大容量数据。
此外，它还可以支持每秒数千条消息的消息吞吐量。
2 低延迟：Kafka可以轻松处理这些消息，具有毫秒级的极低延迟，这是大多数新用例所要求的。
3 容错：Kafka能够抵抗集群中的节点/机器故障。
4 耐久性：由于Kafka支持消息复制，因此消息永远不会丢失。这是耐久性背后的原因之一。
5 可扩展性：Kafka可以扩展，而不需要通过添加额外的节点而在运行中造成任何停机。

6为什么要使用Kafka？为什么要使用消息队列？

1 缓冲和削峰：
上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，
kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
2 解耦和扩展性：
项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。
只需要遵守约定，针对数据编程即可获取扩展能力。
3 冗余：
可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。
4 健壮性：
消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
5 异步通信：
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，
允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

7 Kafka存在那些局限性？

1. 没有完整的监控工具集
2. 消息调整的问题
3. 不支持通配符主题选择
4. 速度问题

8 Kafka为什么不支持读写分离？

在 Kafka中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，
从而实现的是一种主写主读的生产消费模型。
Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:
延时问题
数据一致性问题

9 Kafka如何实现延迟队列？

Kafka并没有使用JDK自带的Timer或者DelayQueue来实现延迟的功能，
而是基于时间轮自定义了一个用于实现延迟功能的定时器
底层使用数组实现，数组中的每个元素可以存放一个TimerTaskList对象。
TimerTaskList是一个环形双向链表，在其中的链表项TimerTaskEntry中封装了真正的定时任务TimerTask.

10 Kafka如何保证消息可靠性

导致消费者弄丢数据的情况就是
拉取了这个消息，然后消费者那边自动提交了,Kafka 以为你已经消费好了这个消息，
但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢了。
解决:
关闭自动提交 offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢
broker弄丢数据
解决:

• 给 topic 设置 replication.factor 参数：这个值必须大于 1，要求每个 partition 必须有至少 2 个副本。
• 在 Kafka 服务端设置 min.insync.replicas 参数：这个值必须大于 1，
  这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower 吧。
• 在 producer 端设置 acks=all：这个是要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了。
• 在 producer 端设置 retries=10000000（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了。
  生产者弄丢数据
  如果设置了 acks=all，一定不会丢，要求是，你的 leader 接收到消息，
  所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次

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

1. 可以设置topic 有且只有一个partition
2. 根据业务需要，需要顺序的 指定为同一个partition
3. 根据业务需要，需要顺序的指定为同一个partition (比如同一个订单，使用同一个key，可以保证分配到同一个partition上)

12创建topic时如何选择合适的分区数？

kafka集群中，单Topic的partition也并不是越多越好，但通常对于业务方来说
需要根据具体的场景进行分析以确定partition的数量。
通常Kafka集群中的分区越多，吞吐量就越高。但是，必须意识到总分区或每个Broker拥有太多分区
对可用性和延迟等方面的潜在影响，通常这部分需要业务方和基础服务方进行合理规划和调整。
一般情况下，分区数可以配置为Broker节点数的整数倍，
比如：Broker节点是3，那么可以设置分区数为3、6、9。
但是不能无限扩展, 有临界值, 临界值多少, 需要通过压测工具进行测试

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

offset+1

14有哪些情形会造成重复消费？

消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

15哪些情景下会造成消息丢失

消消费者没有处理完消息 提交offset(自动提交偏移 未处理情况下程序异常结束)