Java面试题-Kafka，2024年最新高级面试题+解析_kafka面试题2024

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0已经写入了 Message4，但是 Consumer 只能读取到 Message2。 因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。

这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。 如果我们允许消费者读取这些消息，可能就会破坏一致性。 试想，一个消费者从当前 Leader（副本0） 读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。

当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。 延迟时间可以通过参数 replica.lag.time.max.ms 参数配置，它指定了副本在复制消息时可被允许的最大延迟时间。

@、ISR、OSR、AR 是什么？

ISR：In-Sync Replicas 副本同步队列

OSR： Out-of-Sync Replicas

AR：Assigned Replicas 所有副本

ISR是由leader维护，follower从leader同步数据有一些延迟（具体可以参见 图文了解 Kafka 的副本复制机制 ），超过相应的阈值会把 follower 剔除出 ISR, 存入OSR（ Out-of-Sync Replicas ）列表，新加入的follower也会先存放在OSR中。 AR=ISR+OSR。

@、 LEO 、HW、LSO、LW等分别代表什么

• LEO： 是 LogEndOffset 的简称，代表当前日志文件中下一条

• HW： 水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式处理领域（比如Apache Flink、Apache Spark等），以表征元素或事件在基于时间层面上的进度。 在Kafka中，水位的概念反而与时间无关，而是与位置信息相关。 严格来说，它表示的就是位置信息，即位移（offset）。 取 partition 对应的 ISR中 最小的 LEO 作为 HW，consumer 最多只能消费到 HW 所在的位置上一条信息。

• LSO： 是 LastStableOffset 的简称， 对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同

• LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。

@、Kafka 在什么情况下会出现消息丢失？

可以参见我这篇文章： Kafka 是如何保证数据可靠性和一致性

@、怎么尽可能保证 Kafka 的可靠性

可以参见我这篇文章： Kafka 是如何保证数据可靠性和一致性

@、消费者和消费者组有什么关系？

每个消费者从属于消费组。具体关系如下：

@、Kafka 的每个分区只能被一个消费者线程，如何做到多个线程同时消费一个分区？

参见我这篇文章：Airbnb 是如何通过 balanced Kafka reader 来扩展 Spark streaming 实时流处理能力的

@、数据传输的事务有几种？

数据传输的事务定义通常有以下三种级别：

（1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输

（2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.

（3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被

@、Kafka 消费者是否可以消费指定分区消息？

Kafa consumer消费消息时，向broker发出fetch请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的

@、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阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发

@、Kafka 消息格式的演变清楚吗？

Kafka 的消息格式经过了四次大变化，具体可以参见我这篇文章： Apache Kafka消息格式的演变(0.7.x~0.10.x) 。

@、Kafka 偏移量的演变清楚吗？

参见我这篇文章 ： 图解Apache Kafka消息偏移量的演变(0.7.x~0.10.x)

@、 Kafka 高效文件存储设计特点

• Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

• 通过索引信息可以快速定位message和确定response的最大大小。

• 通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。

• 通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小

@、Kafka创建Topic时如何将分区放置到不同的Broker中

• 副本因子不能大于 Broker 的个数；

• 第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；

• 其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；

• 剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的

具体可以参见 Kafka创建Topic时如何将分区放置到不同的Broker中 。

@、Kafka新建的分区会在哪个目录下创建

在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。

当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。

如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。

但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。

具体可以参见我博客：https://www.iteblog.com/archives/2231.html

@、谈一谈 Kafka 的再均衡

在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡： 在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。 Rebalance的过程如下：

第一步： 所有成员都向coordinator发送请求，请求入组。 一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。

第二步： leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。 一旦完成分配，leader会将这个方案发给coordinator。 coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。

所以对于Rebalance来说，Coordinator起着至关重要的作用

@、谈谈 Kafka 分区分配策略

参见我这篇文章 Kafka分区分配策略(Partition Assignment Strategy)

@、Kafka Producer 是如何动态感知主题分区数变化的？

参见我这篇文章：Kafka Producer是如何动态感知Topic分区数变化

@、Kafka 是如何实现高吞吐率的？

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失 。 kafka主要使用了以下几个方式实现了超高的吞吐率 ：

• 顺序读写；

• 零拷贝

• 文件分段

• 批量发送

• 数据压缩。

具体参见：Kafka是如何实现高吞吐率的

@、Kafka 监控都有哪些？

参见我另外几篇文章：Apache Kafka监控之KafkaOffsetMonitor

雅虎开源的Kafka集群管理器(Kafka Manager)

Apache Kafka监控之Kafka Web Console

还有 JMX

@、如何为Kafka集群选择合适的Topics/Partitions数量

参见我另外几篇文章：如何为Kafka集群选择合适的Topics/Partitions数量

@、谈谈你对 Kafka 事务的了解？

参见这篇文章：http://www.jasongj.com/kafka/transaction/

@、谈谈你对 Kafka 幂等的了解？

参见这篇文章：https://www.jianshu.com/p/b1599f46229b

@、Kafka 缺点？

• 由于是批量发送，数据并非真正的实时；

• 对于mqtt协议不支持；

• 不支持物联网传感数据直接接入；

• 仅支持统一分区内消息有序，无法实现全局消息有序；

• 监控不完善，需要安装插件；

• 依赖zookeeper进行元数据管理；

@、Kafka 新旧消费者的区别

旧的 Kafka 消费者 API 主要包括： SimpleConsumer（简单消费者） 和 ZookeeperConsumerConnectir（高级消费者）。 SimpleConsumer 名字看起来是简单消费者，但是其实用起来很不简单，可以使用它从特定的分区和偏移量开始读取消息。 高级消费者和现在新的消费者有点像，有消费者群组，有分区再均衡，不过它使用 ZK 来管理消费者群组，并不具备偏移量和再均衡的可操控性。

现在的消费者同时支持以上两种行为，所以为啥还用旧消费者 API 呢？

@、Kafka 分区数可以增加或减少吗？为什么？

我们可以使用 bin/kafka-topics.sh 命令对 Kafka 增加 Kafka 的分区数据 ，但是 Kafka 不支持减少 分区数。

Kafka 分区数据 不支持减少 是由很多原因的，比如减少的分区 其数据放到哪里去？ 是删除，还是保留？ 删除的话， 那么这些没消费的消息 不就丢了。 如果保留这些消息 如何放到 其他分区里面？ 追加到 其他分区 后面的话 那么就破坏了 Kafka 单个分区的有序性。 如果 要保证删除分区数据插入到其他分区 保证有序性，那么实现起来逻辑就会非常复杂。

@、请说明什么是Apache Kafka?

Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。

@、请说明什么是传统的消息传递方法?

传统的消息传递方法包括两种：

• 排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人。

• 发布-订阅：在这个模型中，消息被广播给所有的用户。

@、请说明Kafka相对传统技术有什么优势?

Apache Kafka与传统的消息传递技术相比优势之处在于：

快速:单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。

可伸缩:在一组机器上对数据进行分区和简化，以支持更大的数据

持久:消息是持久性的，并在集群中进行复制，以防止数据丢失。

设计:它提供了容错保证和持久性

@、在Kafka中broker的意义是什么?

在Kafka集群中，broker术语用于引用服务器。

@、Kafka服务器能接收到的最大信息是多少?

Kafka服务器可以接收到的消息的最大大小是1000000字节。

@、解释Kafka的Zookeeper是什么?我们可以在没有Zookeeper的情况下使用Kafka吗?

Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。

不，不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper停止工作，它就不能服务客户端请求。

• Zookeeper主要用于在集群中不同节点之间进行通信

• 在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取

• 除此之外，它还执行其他活动，如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。

@、解释Kafka的用户如何消费信息?

在Kafka中传递消息是通过使用sendfile API完成的。它支持将字节从套接口转移到磁盘，通过内核空间保存副本，并在内核用户之间调用内核。

@、解释如何提高远程用户的吞吐量?

如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。

@、解释一下，在数据制作过程中，你如何能从Kafka得到准确的信息?

在数据中，为了精确地获得Kafka的消息，你必须遵循两件事: 在数据消耗期间避免重复，在数据生产过程中避免重复。

这里有两种方法，可以在数据生成时准确地获得一个语义:

• 每个分区使用一个单独的写入器，每当你发现一个网络错误，检查该分区中的最后一条消息，以查看您的最后一次写入是否成功

• 在消息中包含一个主键(UUID或其他)，并在用户中进行反复制

@、解释如何减少ISR中的扰动?broker什么时候离开ISR?

ISR是一组与leaders完全同步的消息副本，也就是说ISR中包含了所有提交的消息。ISR应该总是包含所有的副本，直到出现真正的故障。如果一个副本从leader中脱离出来，将会从ISR中删除。

@、Kafka为什么需要复制?

Kafka的信息复制确保了任何已发布的消息不会丢失，并且可以在机器错误、程序错误或更常见些的软件升级中使用。

最后

权威指南-第一本Docker书

引领完成Docker的安装、部署、管理和扩展，让其经历从测试到生产的整个开发生命周期，深入了解Docker适用于什么场景。并且这本Docker的学习权威指南介绍了其组件的基础知识，然后用Docker构建容器和服务来完成各种任务：利用Docker为新项目建立测试环境，演示如何使用持续集成的工作流集成Docker，如何构建应用程序服务和平台，如何使用Docker的API，如何扩展Docker。

总共包含了：简介、安装Docker、Docker入门、使用Docker镜像和仓库、在测试中使用Docker、使用Docker构建服务、使用Fig编配Docke、使用Docker API、获得帮助和对Docker进行改进等9个章节的知识。

关于阿里内部都在强烈推荐使用的“K8S+Docker学习指南”—《深入浅出Kubernetes：理论+实战》、《权威指南-第一本Docker书》，看完之后两个字形容，爱了爱了！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
等9个章节的知识。

[外链图片转存中…(img-Zr6BgRn3-1713556327190)]

[外链图片转存中…(img-zRnBDLva-1713556327191)]

[外链图片转存中…(img-4v50N09T-1713556327191)]

[外链图片转存中…(img-ZngiK529-1713556327192)]

关于阿里内部都在强烈推荐使用的“K8S+Docker学习指南”—《深入浅出Kubernetes：理论+实战》、《权威指南-第一本Docker书》，看完之后两个字形容，爱了爱了！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-Znwg8bXh-1713556327192)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！