Kafka面试题 原创
1、请说明什么是 Apache Kafka
Apache Kafka 是由 Apache 开发的一种发布订阅消息系统,它是一个分布式的、分区的和可复制的提交日志服务。
2、说说 Kafka 的使用场景
① 异步处理
② 应用解耦
③ 流量削峰
④ 日志处理
⑤ 消息通讯等。
3、使用 Kafka 有什么优点和缺点
优点:
① 支持跨数据中心的消息复制;
② 单机吞吐量:十万级,最大的优点,就是吞吐量高;
③topic 数量受吞吐量的影响:topic 从几十个到几百个的时候,吞吐量会大幅度下降。所以在同等机器下,kafka 尽量保证 topic 数量不要过多。如果要支撑大规模 topic,需要增加更多的机器资源;
④ 时效性:ms 级;
⑤ 可用性:非常高,kafka 是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用;
⑥ 消息可靠性:经过参数优化配置,消息可以做到 0 丢失;
⑦ 功能支持:功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用。
缺点:
① 由于是批量发送,数据并非真正的实时; 仅支持统一分区内消息有序,无法实现全局消息有序;
② 有可能消息重复消费;
③ 依赖 zookeeper 进行元数据管理,等等。
4、为什么说 Kafka 性能很好,体现在哪里
① 顺序读写
② 零拷贝
③ 分区
④ 批量发送
⑤ 数据压缩
5、请说明什么是传统的消息传递方法
传统的消息传递方法包括两种:
排队:在队列中,一组用户可以从服务器中读取消息,每条消息都发送给其中一个人。
发布-订阅:在这个模型中,消息被广播给所有的用户。
6、请说明 Kafka 相对传统技术有什么优势
① 快速:单一的 Kafka 代理可以处理成千上万的客户端,每秒处理数兆字节的读写操作。
② 可伸缩:在一组机器上对数据进行分区
③ 和简化,以支持更大的数据
④ 持久:消息是持久性的,并在集群中进
⑤ 行复制,以防止数据丢失。
⑥ 设计:它提供了容错保证和持久性
7、解释 Kafka 的 Zookeeper 是什么我们可以在没有 Zookeeper 的情况下使用 Kafka 吗
Zookeeper 是一个开放源码的、高性能的协调服务,它用于 Kafka 的分布式应用。
不,不可能越过 Zookeeper,直接联系 Kafka broker。一旦 Zookeeper 停止工作,它就不能服务客户端请求。
Zookeeper 主要用于在集群中不同节点之间进行通信
在 Kafka 中,它被用于提交偏移量,因此如果节点在任何情况下都失败了,它都可以从之前提交的偏移量中获取
除此之外,它还执行其他活动,如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
8、解释 Kafka 的用户如何消费信息
在 Kafka 中传递消息是通过使用 sendfile API 完成的。它支持将字节从套接口转移到磁盘,通过内核空间保存副本,并在内核用户之间调用内核。
9、解释如何提高远程用户的吞吐量
如果用户位于与 broker 不同的数据中心,则可能需要调优套接口缓冲区大小,以对长网络延迟进行摊销。
10、解释一下,在数据制作过程中,你如何能从 Kafka 得到准确的信息
在数据中,为了精确地获得 Kafka 的消息,你必须遵循两件事: 在数据消耗期间避免重复,在数据生产过程中避免重复。
这里有两种方法,可以在数据生成时准确地获得一个语义:
每个分区使用一个单独的写入器,每当你发现一个网络错误,检查该分区中的最后一条消息,以查看您的最后一次写入是否成功
在消息中包含一个主键(UUID 或其他),并在用户中进行反复制
11、解释如何减少 ISR 中的扰动 broker 什么时候离开 ISR
ISR 是一组与 leaders 完全同步的消息副本,也就是说 ISR 中包含了所有提交的消息。ISR 应该总是包含所有的副本,直到出现真正的故障。如果一个副本从 leader 中脱离出来,将会从 ISR 中删除。
12、Kafka 为什么需要复制
Kafka 的信息复制确保了任何已发布的消息不会丢失,并且可以在机器错误、程序错误或更常见些的软件升级中使用。
13、如果副本在 ISR 中停留了很长时间表明什么
如果一个副本在 ISR 中保留了很长一段时间,那么它就表明,跟踪器无法像在 leader 收集数据那样快速地获取数据。
14、请说明如果首选的副本不在 ISR 中会发生什么
如果首选的副本不在 ISR 中,控制器将无法将 leadership 转移到首选的副本。
15、有可能在生产后发生消息偏移吗
在大多数队列系统中,作为生产者的类无法做到这一点,它的作用是触发并忘记消息。broker 将完成剩下的工作,比如使用 id 进行适当的元数据处理、偏移量等。
作为消息的用户,你可以从 Kafka broker 中获得补偿。如果你注视 SimpleConsumer 类,你会注意到它会获取包括偏移量作为列表的 MultiFetchResponse 对象。此外,当你对 Kafka 消息进行迭代时,你会拥有包括偏移量和消息发送的 MessageAndOffset 对象。
16、Kafka 的设计时什么样的呢
Kafka 将消息以 topic 为单位进行归纳 将向 Kafka topic 发布消息的程序成为 producers. 将预订 topics 并消费消息的程序成为 consumer. Kafka 以集群的方式运行,可以由一个或多个服务组成,每个服务叫做一个 broker. producers 通过网络将消息发送到 Kafka 集群,集群向消费者提供消息
17、数据传输的事物定义有哪三种
(1)最多一次:
消息不会被重复发送,最多被传输一次,但也有可能一次不传输
(2)最少一次: 消息不会被漏发送,最少被传输一次,但也有可能被重复传输.
(3)精确的一次(Exactly once): 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次,这是大家所期望的
18、Kafka 判断一个节点是否还活着有那两个条件
(1)节点必须可以维护和 ZooKeeper 的连接,Zookeeper 通过心跳机制检查每个节点的连接
(2)如果节点是个 follower,他必须能及时的同步 leader 的写操作,延时不能太久
19、producer 是否直接将数据发送到 broker 的 leader(主节点)
producer 直接将数据发送到 broker 的 leader(主节点),不需要在多个节点进行分发,为了帮助 producer 做到这点,所有的 Kafka 节点都可以及时的告知:哪些节点是活动的,目标 topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了。
20、Kafa consumer 是否可以消费指定分区消息
Kafa consumer 消费消息时,向 broker 发出"fetch"请求去消费特定分区的消息,consumer 指定消息在日志中的偏移量(offset),就可以消费从这个位置开始的消息,customer 拥有了 offset 的控制权,可以向后回滚去重新消费之前的消息,这是很有意义的
21、Kafka 消息是采用 Pull 模式,还是 Push 模式
Kafka 最初考虑的问题是,customer 应该从 brokes 拉取消息还是 brokers 将消息推送到 consumer,也就是 pull 还 push。在这方面,Kafka 遵循了一种大部分消息系统共同的传统的设计:producer 将消息推送到 broker,consumer 从 broker 拉取消息一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式,将消息推送到下游的 consumer。这样做有好处也有坏处:由 broker 决定消息推送的速率,对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息,但不幸的是,push 模式下,当 broker 推送的速率远大于 consumer 消费的速率时,consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式
Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免 consumer 崩溃而采用较低的推送速率,将可能导致一次只推送较少的消息而造成浪费。Pull 模式下,consumer 就可以根据自己的消费能力去决定这些策略
Pull 有个缺点是,如果 broker 没有可供消费的消息,将导致 consumer 不断在循环中轮询,直到新消息到 t 达。为了避免这点,Kafka 有个参数可以让 consumer 阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发
22、Kafka 存储在硬盘上的消息格式是什么
消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32 校验码。
消息长度: 4 bytes (value: 1+4+n)
版本号: 1 byte
CRC 校验码: 4 bytes
具体的消息: n bytes
23、Kafka 高效文件存储设计特点
(1).Kafka 把 topic 中一个 parition 大文件分成多个小文件段,通过多个小文件段,就容易定期清除或删除已经消费完文件,减少磁盘占用。
(2).通过索引信息可以快速定位 message 和确定 response 的最大大小。
(3).通过 index 元数据全部映射到 memory,可以避免 segment file 的 IO 磁盘操作。
(4).通过索引文件稀疏存储,可以大幅降低 index 文件元数据占用空间大小。
24、Kafka 与传统消息系统之间有三个关键区别
(1).Kafka 持久化日志,这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统:它以集群的方式运行,可以灵活伸缩,在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理
25、Kafka 创建 Topic 时如何将分区放置到不同的 Broker 中
副本因子不能大于 Broker 的个数;
第一个分区(编号为 0)的第一个副本放置位置是随机从 brokerList 选择的;
其他分区的第一个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个 Broker,5 个分区,假设第一个分区放在第四个 Broker 上,那么第二个分区将会放在第五个 Broker 上;第三个分区将会放在第一个 Broker 上;第四个分区将会放在第二个 Broker 上,依次类推;
剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的,而这个数也是随机产生的
26、Kafka 新建的分区会在哪个目录下创建
在启动 Kafka 集群之前,我们需要配置好 log.dirs 参数,其值是 Kafka 数据的存放目录,这个参数可以配置多个目录,目录之间使用逗号分隔,通常这些目录是分布在不同的磁盘上用于提高读写性能。 当然我们也可以配置 log.dir 参数,含义一样。只需要设置其中一个即可。 如果 log.dirs 参数只配置了一个目录,那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。 但是如果 log.dirs 参数配置了多个目录,那么 Kafka 会在哪个文件夹中创建分区目录呢答案是:Kafka 会在含有分区目录最少的文件夹中创建新的分区目录,分区目录名为 Topic 名+分区 ID。注意,是分区文件夹总数最少的目录,而不是磁盘使用量最少的目录!也就是说,如果你给 log.dirs 参数新增了一个新的磁盘,新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。
27、partition 的数据如何保存到硬盘
topic 中的多个 partition 以文件夹的形式保存到 broker,每个分区序号从 0 递增, 且消息有序 Partition 文件下有多个 segment(xxx.index,xxx.log) segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为 1g 如果大小大于 1g 时,会滚动一个新的 segment 并且以上一个 segment 最后一条消息的偏移量命名
28、kafka 的 ack 机制
request.required.acks 有三个值 0 1 -1
0:生产者不会等待 broker 的 ack,这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据
1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader 挂掉后他不确保是否复制完成新 leader 也会导致数据丢失
-1:同样在 1 的基础上 服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的 ack,这样数据不会丢失
29、Kafka 的消费者如何消费数据
消费者每次消费数据的时候,消费者都会记录消费的物理偏移量(offset)的位置 等到下次消费时,他会接着上次位置继续消费。同时也可以按照指定的 offset 进行重新消费。
30、消费者负载均衡策略
结合 consumer 的加入和退出进行再平衡策略。
31、kafka 消息数据是否有序
消费者组里某具体分区是有序的,所以要保证有序只能建一个分区,但是实际这样会存在性能问题,具体业务具体分析后确认。
32、kafaka 生产数据时数据的分组策略,生产者决定数据产生到集群的哪个 partition 中
每一条消息都是以(key,value)格式 Key 是由生产者发送数据传入 所以生产者(key)决定了数据产生到集群的哪个 partition
33、kafka consumer 什么情况会触发再平衡 reblance
① 一旦消费者加入或退出消费组,导致消费组成员列表发生变化,消费组中的所有消费者都要执行再平衡。
② 订阅主题分区发生变化,所有消费者也都要再平衡。
34、描述下 kafka consumer 再平衡步骤
① 关闭数据拉取线程,情空队列和消息流,提交偏移量;
② 释放分区所有权,删除 zk 中分区和消费者的所有者关系;
③ 将所有分区重新分配给每个消费者,每个消费者都会分到不同分区;
④ 将分区对应的消费者所有关系写入 ZK,记录分区的所有权信息;
⑤ 重启消费者拉取线程管理器,管理每个分区的拉取线程。