Kafka高频面试题：夺命10连问(1)，java 线程 面试

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

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

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

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

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

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

正文

这里大致可以发传统的方式发生了4次拷贝，2次DMA和2次CPU，而CPU发生了4次的切换。（DMA 简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情）

零拷贝的方式

======

通过优化我们可以发现，CPU只发生了2次的上下文切换和3次数据拷贝。（linux系统提供了系统事故调用函数“ sendfile()”，这样系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态）。

3.4 分区分段技术

==========

kafka采取了分区的模式，而每一个分区又对应到一个物理分段，而查找的时候可以根据二分查找快速定位。这样不仅提供了数据读的查询效率，也提供了并行操作的方式。

比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中 小的offset命名。这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。

3.5数据压缩技术

=========

Kafka对数据提供了：Gzip和Snappy压缩协议等压缩协议，对消息结构体进行了压缩，一方面减少了带宽，也减少了数据传输的消耗。

四 Kafka为什么不支持读写分离

=================

Kafka是采用主读主写的生产、消费模式。也就是说，无论是生产者向Kafka写入数据还是消费者从Kafka集群消费数据都是和Leader副本打交道。

那么主写主读有什么有点呢？

1. 代码逻辑简单，降低了出错的可能性。

2. 与主写从读的方式相比，负载均衡的效果会更好，同时能够将负载粒度更均衡化。

3. 主写主读的方式，延迟性非常小，在Leader副本稳定的情况下，很难出现数据不一致的情况。

五 你是怎么理解Kafka的offset的？

======================

5.1 Kafka一共有两种offset

====================

关于Offset，在Kafka内一共有分区offset和消费offset。

5.1.1 分区offset

==============

在生产者向Kafka写入数据时，每条消息在Partition内都会有一个对应的位置，如果一个Producer向Kafka的某个分区写入了10条数据，那么这10条消息对应的offset依次是0、1、2、。。。、9。

5.1.2 消费offset

==============

消费者需要记录消费进度，用来记录消费到某个Partition的什么位置了，这就是消费者offset。

5.1.3 两种offset不是同一个概念

=====================

分区offset是分区内消息的位置，它是不变的，即一旦消息被成功写到一个分区之后，它的offset就不会发生变化了。而消费offset则不同，它是随时变化的，它用来指示消费的进度，下面我们重点介绍一下消费offset。

5.2 Kafka的消费offset

==================

消费offset，记录的是消费者要消费的下一条消息的位移，而不是当前正在消费的消息位移。

例如，一个分区内有10条消息，offset分别为0到9，某个消费者消费了5条消息，此时消费位移是5，指向了下一条消息的位移。

六 谈一谈Kafka的Rebalance技术

======================

在消费Kafka的数据时，当有新的消费者加入消费者组，或者订阅的topic数发生变化时，都会触发Rebalance的发生（在同一个消费者组中，分区的所有权从一个消费者转移到另外一个消费者）。Rebalance的过程是这样的：

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

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

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

七 简单的说说Kafka的事务是怎么回事？

=====================

Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

7.1Producer 事务

==============

为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的 Transaction ID 获得原来的 PID。

为了管理 Transaction， Kafka 引入了一个新的组件 Transaction Coordinator。 Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。 Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

7.2Consumer 事务

==============

上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

八 在哪些情况下会进行Kafka分区Leader的选举？

============================

分区的Leader副本选举对用户是完全透明的，它是由Controller独立完成的。一共有4种场景会触发分区Leader选举，这4类选举策略的大致思想是类似的，即从AR中挑选首个在ISR中的副本，作为新Leader。

8.1 OfflinePartition Leader选举

=============================

每当有分区上线时，就需要执行Leader选举。所谓的分区上线，可以是创建了新分区，也可以是之前的下线分区重新上线。这是最常见的分区Leader选举场景。

8.2 ReassignPartition Leader选举

==============================

当你手动运行kafka-reassign-partitions命令，或者是调用Admin的

alterPartitionReassignments方法执行分区副本重分配时，可能触发此类选举。假设原来的AR是[1，2，3]，Leader是1，当执行副本重分配后，副本集合AR被设置成[4，5，6]，显然，Leader必须要变更，此时会发生Reassign Partition Leader选举。

8.3 PreferredReplicaPartition Leader选举

======================================

当你手动运行

kafka-preferred-replica-election命令，或自动触发了Preferred Leader选举时，该类策略被激活。所谓的Preferred Leader，指的是AR中的第一个副本。比如AR是[3，2，1]，那么，Preferred Leader就是3。

8.4 ControlledShutdownPartition Leader选举

========================================

当Broker正常关闭时，该Broker上的所有Leader副本都会下线，因此，需要为受影响的分区执行相应的Leader选举。

九 如何理解Kafka中的Consumer Group

===========================

Consumer Group是一个逻辑上的概念。在同一个Topic中的数据，可能会被不同的消费者组订阅；而同一个消费者组内，通常会有多个消费者。对于同一个Topic，每个消费者组都能拿到同样的数据，但是每条数据都只会被消费者组内的一个消费者消费。消费者组内的消费者可以通过多进程的方式消费，也可以利用Partition将进程分布在不同的机器上，同组的消费者数量通常不会超过Partition的数量，且二者的关系最好是整数倍关系，因为Kafka在设计时就假定了一个Partition只能被一个消费者消费（同一组内）。

十 在Kafka集群里面，ZooKeeper主要是用来做什么的？

================================

在Kafka的2.8.0版本之后，已经完全脱离的ZooKeeper，相信这道题主要是考察在之前版本的中，ZooKeeper的作用。

zookeeper 存储了一些关于 consumer 和 broker 的信息，那么就从这两方面说明 zookeeper 的作用。

10.1 broker

===========

10.1.1 状态

=========

zookeeper 记录了所有 broker 的存活状态，broker 会向 zookeeper 发送心跳请求来上报自己的状态。

zookeeper 维护了一个正在运行并且属于集群的 broker 列表。

10.1.2 控制器选举

============

kafka 集群中有多个 broker，其中有一个会被选举为控制器。

控制器负责管理整个集群所有分区和副本的状态，例如某个分区的 leader 故障了，控制器会选举新的 leader。

从多个 broker 中选出控制器，这个工作就是 zookeeper 负责的。

10.1.3 限额权限

===========

kafka 允许一些 client 有不同的生产和消费的限额。这些限额配置信息是保存在 zookeeper 里面的。所有 topic 的访问控制信息也是由 zookeeper 维护的。

10.1.4 记录 ISR

=============

ISR（in-sync replica） 是 partition 的一组同步集合，就是所有 follower 里面同步最积极的那部分。一条消息只有被 ISR 中的成员都接收到，才被视为“已同步”状态。只有处于 ISR 集合中的副本才有资格被选举为 leader。zookeeper 记录着 ISR 的信息，而且是实时更新的，只要发现其中有成员不正常，马上移除。

10.1.5 node 和 topic 注册

======================

zookeeper 保存了所有 node 和 topic 的注册信息，可以方便的找到每个 broker 持有哪些 topic。node 和 topic 在 zookeeper 中是以临时节点的形式存在的，只要与 zookeeper 的 session 一关闭，他们的信息就没有了。

最后

做任何事情都要用心，要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局，思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局，未来你的路会走的更远。

更多的技术点思维导图我已经做了一个整理，涵盖了当下互联网最流行99%的技术点，在这里我将这份导图分享出来，以及为金九银十准备的一整套面试体系，上到集合，下到分布式微服务

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

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

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

[外链图片转存中…(img-O2sOpEgC-1713264596248)]

[外链图片转存中…(img-4xJBy8cD-1713264596248)]

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

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

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