Kafka面试题

kafka是一个分布式消息（系统/队列），是一个集群。

kafka中数据不是永久存储，默认是保存7天。

目录

1.Kafka与HDFS对比

2.kafka为什么可以实现高效传输数据

2.kafka的组成

3.消费者组

4.Kafka优势和使用场景

5.flume与kafka

6.kafka一定要用zookeeper吗？

7.kafka中是怎么做到消息顺序性的？

8.kafka消息堆积问题

9.Kafka数据会不会丢失？

10.Broker宕机会不会导致数据丢失？

---

1.Kafka与HDFS对比

hdfs是一个分布式文件系统，用于存储文件，而kafka就类似hdfs，但是存储的是消息，kafka的broker节点相当于hdfs的datanode节点。

kafak没有类似namenode节点来管理元数据和集群，所以要借助zookeeper 来管理、保存集群的元数据和消费者信息。（kafka2.8版本之后可以不借助zookeeper）

2.kafka为什么可以实现高效传输数据

1. 顺序写入磁盘：Kafka采用顺序写入磁盘的方式，相比随机写入内存，顺序写入磁盘的速度更快。这是因为顺序写入可以利用磁盘的预读特性，提前将数据加载到缓存中，减少了磁盘I/O操作的次数。
2. 利用Page Cache：Kafka充分利用了操作系统的Page Cache机制。当数据写入Kafka时，首先被写入Page Cache中，而不是直接写入磁盘。这样可以减少对磁盘的访问次数，提高写入性能。同时，读取数据时也可以直接从Page Cache中获取，避免了磁盘I/O操作的延迟。
3. 零拷贝技术：操作系统的设计就是每个应用程序都有自己的用户内存，想要实现数据传输，就需要不断从各个缓冲区中拷贝，而Kafka使用了零拷贝技术，减少了不必要的内存拷贝操作。在数据发送过程中，Kafka可以直接将数据从Page Cache中发送到网络缓冲区，无需先将数据拷贝到应用程序缓冲区再发送，从而减少了CPU和内存的开销。
4. 批量处理：Kafka支持批量处理消息，这意味着它可以在一次磁盘操作中写入或读取多条消息，进一步提高了磁盘I/O效率。
5. 可扩展性：Kafka的设计具有良好的可扩展性，可以轻松地扩展到数百台服务器，并处理每秒数百万条消息。这种可扩展性使得Kafka能够处理大量的数据，满足各种大规模数据处理需求。

2.kafka的组成

• producer：消息发送者
• consumer：消息接收者
• broker：kafka集群各个节点
• topic：消息保存时按照topic归类，producer和consumer发送和接收消息时需要指定topic

多个producer和consumer可以共享同一个或多个topic：一对多，多对一，多对多。

3.消费者组

消费者以组group的名义订阅topic，topic下有多个partition，消费者组中有多个消费者实例。

同一时刻，一条消息只能被组中的一个消费者实例消费。即每个partition只从属于组中的一个消费者，不可能出现组中的两个消费者负责同一个partition。
 分区partition是为了提高并行消费的能力。

4.Kafka优势和使用场景

优势：

1. 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
2. 可扩展性：kafka集群支持热扩展
3. 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
4. 容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）
5. 高并发：支持数千个客户端同时读写

使用场景：

1. 消息队列：比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区，冗余及容错性，这让Kafka成为了一个很好的大规模消息处理应用的解决方案
2. 行为跟踪：将网页点击/用户操作等消息发送到kafka中，并实时监控，或者离线统计分析等
3. 日志收集：将操作日志发送到kafka集群而不是保存在本地/数据库中，kafka可以批量提交/压缩消息等，处理延迟更低，这对于producer端几乎感受不到性能的开支，此时consumer端可以使用hadoop等其他系统化的存储、分析系统
4. 流处理：保存收集的流数据，以提供之后对接的Storm或其他流式计算框架进行处理。

5.flume与kafka

flume可以与kafka一起工作，kafka是分布式消息中间件，自带存储，更适合做日志缓存，flume更适合做日志采集，然后把采集的数据发送到kafka中，再由kafka把数据传送给hadoop、spark等消费者。

6.kafka一定要用zookeeper吗？

不一定，kafka2.8之前必须依赖zookeeper，2.8之后的kafka可以不用zookeeper，而且使用组件KRaft（分布式协议）来管理集群。

7.kafka中是怎么做到消息顺序性的？

kafka只保证单partition有序，如果Kafka要保证多个partition有序，不仅broker保存的数据要保持顺序，消费时也要按序消费。假设partition1堵了，为了有序，那partition2以及后续的分区也不能被消费，这种情况下，Kafka 就退化成了单一队列，毫无并发性可言，极大降低系统性能。因此Kafka使用多partition的概念，并且只保证单partition有序。这样不同partiiton之间不会干扰对方。

1. 方法一：全局消费顺序，一个topic只创建一个prtition，生产者的所有数据都发送到一个partition，保证了消息的顺序性
2. 方法二：局部消费顺序，生产者在发送消息时指定发送到哪个partition，保证了该生产者的消息顺序性

8.kafka消息堆积问题

消息堆积/数据积压原因：系统中的某个部分出现了性能问题，来不及处理上游producer发送的数据，导致了数据积压。（生产者生产数据速度>>消费者消费数据速度）

解决：

1. 可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数 = 分区数。
2. 提高每批次拉取的数量，提高单个消费者的消费能力。
3. 如果下游是 Spark 、 Flink 等计算引擎，当计算能力跟不上消费能力时也会导致数据挤压，可以对计算性能进行优化。

9.Kafka数据会不会丢失？

1. 生产者角度：生产者发送消息到 Kafka 服务器的过程可能会发生网络波动，导致消息丢失。解决：设置ack 策略，生产者需要接收来自服务端的 ack 确认，当收不到确认或者超时时，便会抛出异常，从而让生产者可以进一步进行处理（重新发送）。
2. Broker角度：Kafka接收到消息后，其并不直接写入磁盘，而是先写入内存中，如果Broker断电或宕机，那么消息也就丢失了。解决：可以设置每次来一条消息，就会刷一次磁盘，降低消息丢失概率，但是磁盘IO会增加。
3. 消费者角度：如果其拉取消息之后自动返回 ack，但消费者服务在处理过程中发生崩溃退出，此时这条消息就相当于丢失了。解决：业务处理完之后，手动提交 ack 的方式来避免消息丢失。

10.Broker宕机会不会导致数据丢失？

多副本冗余机制：在kafka集群中，每个Partition都有多个副本，其中一个副本叫做leader，其他的副本叫做follower，多副本冗余机制可以保证任何一台机器挂掉，都不会导致数据彻底丢失，因为起码还是有副本在别的机器上的。

多副本如何同步数据：如果有一个客户端往一个Partition写入数据，此时一般就是写入这个Partition的Leader副本，Leader副本接收到数据之后，Follower副本会不停的给他发送请求尝试去拉取最新的数据，拉取到自己本地后，写入磁盘中。