Kafka面试

最新推荐文章于 2024-07-24 11:51:02 发布

IT__LS

最新推荐文章于 2024-07-24 11:51:02 发布

阅读量611

点赞数

分类专栏：面试 Kafka 文章标签： kafka

本文链接：https://blog.csdn.net/it__ls/article/details/126482840

版权

面试同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

Kafka

1 篇文章 0 订阅

订阅专栏

文章内容转自: 华仔聊技术(Kafka 面试连环炮)

一.初级

1.Kafka核心组件图

2.在 Kafka 中 Zookeeper 作用是什么?

3.生产者有哪些发消息的模式？

4.Kafka 如何合理设置分区数,越多越好吗？

Kafka 如何合理设置分区数

分区设置越多越好吗？

5.如何保证 Kafka 中的消息是有序的？

6.Kafka 副本有哪两种，作用是什么？

7.Kafka 读写数据这么快是如何做到的？

顺序追加写

Page Cache

零拷贝技术

8.Kafka中Offset的作用是什么,如何进行维护？

位移 Offset 管理方式

__consumer_offsets 创建

二.中级

9.谈谈你对 kafka 的集群架构是如何理解的？

谈谈你对 Kafka 消息语义是如何理解的？

Producer端

Consumer端

谈谈你对 Kafka 副本机制是如何理解的？

副本同步机制

副本管理

ISR 副本集合

谈谈你对Kafka Leader选举机制是如何理解？

谈谈你对Kafka控制器及选举机制是如何理解？

谈谈 kafka 的数据可靠性是怎么保证的？

谈谈Kafka线上大量消息积压你是如何处理的？

一.初级

1.Kafka核心组件图

2.在 Kafka 中 Zookeeper 作用是什么?

Kafka 集群能够正常工作，目前还是需要依赖于 ZooKeeper，主要用来「负责 Kafka集群元数据管理，集群协调工作」，在每个 Kafka 服务器启动的时候去连接并将自己注册到 Zookeeper，类似注册中心。
Kafka 使用 Zookeeper 存放「集群元数据」、「集群成员管理」、「Controller 选举」、「其他管理类任务」等。待 KRaft 提案完成后，Kafka 将完全不依赖 Zookeeper。

3.生产者有哪些发消息的模式？

发后即忘模式「fire-and-forget」，它只管发送消息，并不需要关心消息是否发送成功。本质上也是异步发送的方式, 吞吐量高但会导致消息丢失；

同步发送模式「sync」，调用 send() 方法会返回一个 Future 对象，再通过调用 Future 对象的 get() 方法，等待结果返回，根据返回的结果可以判断消息是否发送成功， 由于是同步发送会阻塞，只有当消息通过 get() 返回数据时，才会继续下一条消息的发送。

异步发送模式「async」，在调用 send() 方法的时候指定一个 callback 函数，当 Broker 接收到返回的时候，该 callback 函数会被触发执行，通过回调函数能够对异常情况进行处理，当调用了回调函数时，只有回调函数执行完毕生产者才会结束，否则一直会阻塞。

max_in_flight_requests_per_connection 限制客户端在单个连接上能够发送的未响应请求的个数

4.Kafka 如何合理设置分区数,越多越好吗？

Kafka 如何合理设置分区数

分区设置越多越好吗？

Kafka 高吞吐量的原因之一就是通过 Partition 将 Topic 中的消息均衡保存到 Kafka 集群中不同的 Broker 中。

理论上说，如果一个 Topic 分区越多，整个集群所能达到的吞吐量就越大。

消耗文件句柄方面分析

端到端的延迟方面分析

高可用性方面分析

5.如何保证 Kafka 中的消息是有序的？

我们知道在 Kafka 中，并不保证消息全局有序，但是可以保证分区有序性，分区与分区之间是无序的。那么如何保证 Kafka 中的消息是有序的呢？可以从以下三个方面来入手分析：

生产端 Producer

要严格保证 Kafka 发消息有序，首先要考虑用同步的方式来发送消息, 两种同步发送的方式如下:

服务端 Broker

消费端 Consumer

在 Consumer 端，根据 Kafka 的模型，一个 Topic 下的每个分区只能从属于这个 Topic 的消费者组中的某一个消费者。

当消息被发送分配到同一个 Partition 中，消费者从 Partition 中取出来数据的时候，也一定是有顺序的，没有错乱。

但是消费者可能会有多个线程来并发来消费消息。如果单线程消费数据，吞吐量太低了，而多个线程并发消费的话，顺序可能就乱掉了。

此时可以通过写多个内存队列，将相同 key 的消息都写入同一个队列，然后对于多个线程，每个线程分别消息一个队列即可保证消息顺序。

6.Kafka 副本有哪两种，作用是什么？

为为实现「数据备份」的功能 Kafka 提供了副本机制，一个 Topic 的每个 Partition 都有若干个副本，一个 Leader 副本和若干个 Follower 副本 .

7.Kafka 读写数据这么快是如何做到的？

顺序追加写

kafka 在写数据的时是以「磁盘顺序写」的方式来进行落盘的, 即将数据追加到文件的末尾。对于普通机械磁盘, 如果是随机写的话, 涉及到磁盘寻址的问题, 导致性能极低, 但是如果只是按照顺序的方式追加文件末尾的话, 这种磁盘顺序写的性能基本可以跟写内存的性能差不多的。

Page Cache

首先 Kafka 为了保证磁盘写入性能，通过 mmap 内存映射的方式利用操作系统的 Page Cache 异步写入。也可以称为 os cache，意思就是操作系统自己管理的缓存。那么在写磁盘文件的时候，就可以先直接写入 os cache 中，接下来由操作系统自己决定什么时候把 os cache 里的数据真正刷入到磁盘中, 这样大大提高写入效率和性能。

零拷贝技术

kafka 为了解决内核态和用户态数据不必要 Copy 这个问题, 在读取数据的时候就引入了「零拷贝技术」。即让操作系统的 os cache 中的数据直接发送到网卡后传出给下游的消费者，中间跳过了两次拷贝数据的步骤，从而减少拷贝的 CPU 开销, 减少用户态内核态的上下文切换次数, 从而优化数据传输的性能, 而Socket缓存中仅仅会拷贝一个描述符过去，不会拷贝数据到Socket缓存，如下图所示：

消息批量发送

Kafka 在发送消息的时候并不是一条条的发送的，而是会把多条消息合并成一个批次Batch 进行处理发送，消费消息也是同样，一次拉取一批次的消息进行消费。

8.Kafka中Offset的作用是什么,如何进行维护？

在 Kafka 中每个 Topic 分区下面的每条消息都被赋予了一个唯一的ID值，用来标识它在分区中的位置。这个ID值就被称为位移「Offset」或者叫偏移量，一旦消息被写入到日志分区中，它的位移值将不能被修改。

位移 Offset 管理方式

__consumer_offsets 创建

当 Kafka 集群中的第一个 Consumer 启动时， Kafka 会自动创建__consumer_offsets。

这个依赖 Broker 端参数主题分区位移个数即「offsets.topic.num.partitions」 默认值是50，因此 Kafka 会自动创建一个有 50 个分区的 __consumer_offsets 。既然有分区数，必然就会有分区对应的副本个数，这个是依赖 Broker 端另外一个参数来完成的，即 「offsets.topic.replication.factor」默认值为3。

总结一下， __consumer_offsets 由 Kafka 自动创建的，那么该 Topic 的分区数是 50，副本数是 3 ，而具体 Consumer Group 的消费情况要存储到哪个 Partition ，根据 abs(GroupId.hashCode()) % NumPartitions 来计算的，这样就可以保证 Consumer Offset 信息与 Consumer Group 对应的 Coordinator 处于同一个 Broker 节点上。

二.中级

9.谈谈你对 kafka 的集群架构是如何理解的？

Kafka 整体架构图

Kafka存储机制

Kafka 副本机制

Kafka 网络模型

10.谈谈你对 Kafka 消息语义是如何理解的？

Producer端

生产者发送语义：首先当 Producer 向 Broker 发送数据后，会进行消息提交，如果成功消息不会丢失。因此发送一条消息后，可能会有几种情况发生：

Consumer端

消费者接收语义：从 Consumer 角度来剖析，我们知道 Offset 是由 Consumer 自己来维护的。

11.谈谈你对 Kafka 副本机制是如何理解的？

同一个分区下的所有副本保存相同的消息数据，这些副本分散保存在不同的 Broker 上，保证了 Broker 的整体可用性。

副本同步机制

Kafka 中 只有 Leader 副本才能对外进行读写服务，所以解决同步问题，Kafka 是采用基于 Leader 的副本机制 来完成的。

副本管理

ISR 副本集合

Follower 副本不提供服务，只是定期地异步拉取 Leader 副本中的数据。既然是异步的，就一定会存在不能与 Leader 实时同步的情况出现。

Kafka 为了解决这个问题，引入了「 In-sync Replicas」机制，即 ISR 副本集合。要求 ISR 副本集合中的 Follower 副本都是与 Leader 同步的副本。

首先要明确的，Leader 副本天然就在 ISR 副本集合中。另外，能够进入到 ISR 副本集合的 Follower 副本要满足一定的条件。

完全依赖于 Broker 端参数 replica.lag.time.max.ms 参数值，这个参数是指 Follower 副本能够落后 Leader 副本的最长时间间隔，当前默认值是 10 秒，从 2.5 版本开始，默认值从 10 秒增加到 30 秒。即只要一个 Follower 副本落后Leader 副本的时间不连续超过 30 秒，Kafka 就认为该 Follower 副本与 Leader 是同步的，即使 Follower 副本中保存的消息明显少于 Leader 副本中的消息。

此时如果这个副本同步过程的速度持续慢于 Leader 副本的消息写入速度的时候，那么在 replica.lag.time.max.ms 时间后，该 Follower 副本就会被认为与 Leader 副本是不同步的，因此 Kafka 会自动收缩，将其踢出 ISR 副本集合中。后续如果该副本追上了 Leader 副本的进度的话，那么它是能够重新被加回 ISR副本集合的。

在默认情况下，当 Leader 副本发生故障时，只有在 ISR 副本集合中的 Follower 副本才有资格被选举为新 Leader ，而 OSR 中副本集合的副本是没有机会的（可以通过 unclean.leader.election.enable 进行配置执行脏选举）。

总结：ISR 副本集合是一个动态调整的集合。

12.谈谈你对Kafka Leader选举机制是如何理解？

这里所说的 Leader 选举是指分区 Leader 副本的选举，它是由 Kafka Controller 负责具体执行的，当创建分区或分区副本上线的时候都需要执行 Leader 的选举动作。

13.谈谈你对Kafka控制器及选举机制是如何理解？

控制器机制

控制器数据分布

控制器故障转移

在 Kafka 集群运行过程中，只能有一台 Broker 充当控制器的角色，存在「单点故障」的风险， Kafka 如何应对单点故障呢？
其实 Kafka 为控制器提供故障转移功能「Failover」。指当运行中的控制器突然宕机时，Kafka 能够快速地感知到，并立即启用备用控制器来代替之前失败控制器的过程。

控制器触发选举场景

Broker 启动时，会尝试去 ZooKeeper 中创建 /controller 节点，第一个成功创建 /controller 节点的 Broker 会被选为控制器。

场景一、集群首次启动时：

场景二、Broker 监听 /controller 节点消失时：

场景三、Broker 监听 /controller 节点数据变化时：

控制器选举机制

选举最终都是通过调用底层的 elect 方法进行选举

14.谈谈 kafka 的数据可靠性是怎么保证的？

Leader Epoch 机制来规避数据丢失

因此 Kafka 只对「已提交」的消息做「最大限度的持久化保证不丢失」.

15.谈谈Kafka线上大量消息积压你是如何处理的？

消息大量积压这个问题，直接原因一定是某个环节出现了性能问题，来不及消费消息，才会导致消息积压。此时假如 Kafka 集群的磁盘都快写满了，都没有被消费，这个时候怎么办？

优化性能来避免消息积压

对于 Kafka 性能的优化，主要体现在生产者和消费者这两部分业务逻辑中。

发送端性能优化:

发送端即生产者业务代码都是先执行自己的业务逻辑，最后再发送消息。如果说性能上不去，需要你优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。

另外还需要关注下消息体是否过大，如果消息体过大，势必会增加 IO 的耗时，影响 Kafka 生产和消费的速度，也可能会造成消息积压。

消费端性能优化:

在使用 Kafka 时，大部分的性能问题都出现在消费端，如果消费的速度跟不上发送端生产消息的速度，就会造成消息积压. 所以我们在设计的时候，一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。

消费端的性能优化除了优化业务逻辑外，也可以通过水平扩容，增加消费端的并发数来提升总体的消费性能。需要注意的是，在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区数量，确保 Consumer 的实例数和分区数量是相等的，如果 Consumer 的实例数量超过分区数量，这样的扩容实际上是没有效果的。