Kafka大厂高频面试题：在保证高性能、高吞吐的同时保证高可用性(1)

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

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

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

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

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

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

正文

1.场景

====

幂等性并不能跨多个分区运作，而事务可以弥补这个缺憾，事务可以保证对多个分区写入操作的原子性。操作的原子性是指多个操作要么全部成功，要么全部失败，不存在部分成功部分失败的可能。

为了实现事务，应用程序必须提供唯一的transactionalId，这个参数通过客户端程序来进行设定。

见代码库：

com.heima.kafka.chapter7.ProducerTransactionSend

properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, transactionId);

2.前期准备

======

事务要求生产者开启幂等性特性，因此通过将transactional.id参数设置为非空从而开启事务特性的同时需要将

ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG设置为true（默认值为true），如果显示设置为false，则会抛出异常。

KafkaProducer提供了5个与事务相关的方法，详细如下：

//初始化事务，前提是配置了transactionalId public void initTransactions()

//开启事务 public void beginTransaction()

//为消费者提供事务内的位移提交操作 public void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets, String consumerGroupId)

//提交事务 public void commitTransaction()

//终止事务，类似于回滚 public void abortTransaction()

3.案例解析

======

见代码库：

com.heima.kafka.chapter7.ProducerTransactionSend

消息发送端

/**

* Kafka Producer事务的使用

*/ public class ProducerTransactionSend {

public static final String topic = “topic-transaction”;

public static final String brokerList = “localhost:9092”;

public static final String transactionId = “transactionId”;

public static void main(String[] args) {

Properties properties = new Properties();

properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, brokerList);

properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, transactionId);

KafkaProducer<String, String> producer = new KafkaProducer<> (properties);

producer.initTransactions();

producer.beginTransaction();

try {            //处理业务逻辑并创建ProducerRecord

ProducerRecord<String, String> record1 = new ProducerRecord<>(topic, “msg1”);

producer.send(record1);

ProducerRecord<String, String> record2 = new ProducerRecord<>(topic, “msg2”);

producer.send(record2);

ProducerRecord<String, String> record3 = new ProducerRecord<>(topic, “msg3”);

producer.send(record3);

//处理一些其它逻辑

producer.commitTransaction();

} catch (ProducerFencedException e) {

producer.abortTransaction();

}

producer.close();

}

}

模拟事务回滚案例

try {

//处理业务逻辑并创建ProducerRecord

ProducerRecord<String, String> record1 = new ProducerRecord<>(topic, “msg1”);

producer.send(record1);

//模拟事务回滚案例

System.out.println(1/0);

ProducerRecord<String, String> record2 = new ProducerRecord<>(topic, “msg2”);

producer.send(record2);

ProducerRecord<String, String> record3 = new ProducerRecord<>(topic, “msg3”);

producer.send(record3);

//处理一些其它逻辑

producer.commitTransaction();

} catch (ProducerFencedException e) {

producer.abortTransaction();

}

从上面案例中，msg1发送成功之后，出现了异常事务进行了回滚，则msg1消费端也收不到消息。

三、控制器

=====

在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配。

Kafka中的控制器选举的工作依赖于Zookeeper，成功竞选为控制器的broker会在Zookeeper中创建/controller这个临时（EPHEMERAL）节点，此临时节点的内容参考如下：

1.ZooInspector管理

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

• 使用zookeeper图形化的客户端工具(ZooInspector)提供的jar来进行管理，启动如下：

1. 定位到jar所在目录

2. 运行jar文件 java -jar zookeeper-dev-ZooInspector.jar

3. 连接Zookeeper

{“version”:1,“brokerid”:0,“timestamp”:“1529210278988”}

其中version在目前版本中固定为1，brokerid表示称为控制器的broker的id编号，timestamp表示竞选称为控制器时的时间戳。

在任意时刻，集群中有且仅有一个控制器。每个broker启动的时候会去尝试去读取/controller节点的brokerid的值，如果读取到brokerid的值不为-1，则表示已经有其它broker节点成功竞选为控制器，所以当前broker就会放弃竞选；如果Zookeeper中不存在/controller这个节点，或者这个节点中的数据异常，那么就会尝试去创建/controller这个节点，当前broker去创建节点的时候，也有可能其他broker同时去尝试创建这个节点，只有创建成功的那个broker才会成为控制器，而创建失败的broker则表示竞选失败。每个broker都会在内存中保存当前控制器的brokerid值，这个值可以标识为activeControllerId。

Zookeeper中还有一个与控制器有关的/controller_epoch节点，这个节点是持久（PERSISTENT）节点，节点中存放的是一个整型的controller_epoch值。controller_epoch用于记录控制器发生变更的次数，即记录当前的控制器是第几代控制器，我们也可以称之为“控制器的纪元”。

controller_epoch的初始值为1，即集群中第一个控制器的纪元为1，当控制器发生变更时，没选出一个新的控制器就将该字段值加1。每个和控制器交互的请求都会携带上controller_epoch这个字段，如果请求的controller_epoch值小于内存中的controller_epoch值，则认为这个请求是向已经过期的控制器所发送的请求，那么这个请求会被认定为无效的请求。如果请求的controller_epoch值大于内存中的controller_epoch值，那么则说明已经有新的控制器当选了。由此可见，Kafka通过controller_epoch来保证控制器的唯一性，进而保证相关操作的一致性。

具备控制器身份的broker需要比其他普通的broker多一份职责，具体细节如下：

1. 监听partition相关的变化。

2. 监听topic相关的变化。

3. 监听broker相关的变化。

4. 从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理。

四、可靠性保证

=======

1. 可靠性保证：确保系统在各种不同的环境下能够发生一致的行为

2. Kafka的保证

3. 保证分区消息的顺序如果使用同一个生产者往同一个分区写入消息，而且消息B在消息A之后写入那么Kafka可以保证消息B的偏移量比消息A的偏移量大，而且消费者会先读取消息A再读取消息B

4. 只有当消息被写入分区的所有同步副本时（文件系统缓存），它才被认为是已提交

5. 生产者可以选择接收不同类型的确认，控制参数 acks

6. 只要还有一个副本是活跃的，那么已提交的消息就不会丢失

7. 消费者只能读取已经提交的消息

1. 失效副本

========

怎么样判定一个分区是否有副本是处于同步失效状态的呢？从Kafka 0.9.x版本开始通过唯一的一个参数replica.lag.time.max.ms（默认大小为10,000）来控制，当ISR中的一个follower副本滞后leader副本的时间超过参数replica.lag.time.max.ms指定的值时即判定为副本失效，需要将此follower副本剔出除ISR之外。具体实现原理很简单，当follower副本将leader副本的LEO（Log End Offset，每个分区最后一条消息的位置）之前的日志全部同步时，则认为该follower副本已经追赶上leader副本，此时更新该副本的lastCaughtUpTimeMs标识。Kafka的副本管理器（ReplicaManager）启动时会启动一个副本过期检测的定时任务，而这个定时任务会定时检查当前时间与副本的lastCaughtUpTimeMs差值是否大于参数replica.lag.time.max.ms指定的值。千万不要错误地认为follower副本只要拉取leader副本的数据就会更新lastCaughtUpTimeMs，试想当leader副本的消息流入速度大于follower副本的拉取速度时，follower副本一直不断的拉取leader副本的消息也不能与leader副本同步，如果还将此follower副本置于ISR中，那么当leader副本失效，而选取此follower副本为新的leader副本，那么就会有严重的消息丢失。

2.副本复制

======

Kafka 中的每个主题分区都被复制了 n 次，其中的 n 是主题的复制因子（replication factor）。这允许Kafka 在集群服务器发生故障时自动切换到这些副本，以便在出现故障时消息仍然可用。Kafka 的复制是以分区为粒度的，分区的预写日志被复制到 n 个服务器。 在 n 个副本中，一个副本作为 leader，其他副本成为 followers。顾名思义，producer 只能往 leader 分区上写数据（读也只能从 leader 分区上进行），followers 只按顺序从 leader 上复制日志。

一个副本可以不同步Leader有如下几个原因 慢副本：在一定周期时间内follower不能追赶上leader。最常见的原因之一是I / O瓶颈导致follower追加复制消息速度慢于从leader拉取速度。 卡住副本：在一定周期时间内follower停止从leader拉取请求。follower replica卡住了是由于GC暂停或follower失效或死亡。

新启动副本：当用户给主题增加副本因子时，新的follower不在同步副本列表中，直到他们完全赶上了leader日志。

如何确定副本是滞后的

replica.lag.max.messages=4

在服务端现在只有一个参数需要配置replica.lag.time.max.ms。这个参数解释replicas响应partition leader的最长等待时间。检测卡住或失败副本的探测——如果一个replica失败导致发送拉取请求时间间隔超过replica.lag.time.max.ms。Kafka会认为此replica已经死亡会从同步副本列表从移除。检测慢副本机制发生了变化——如果一个replica开始落后leader超过replica.lag.time.max.ms。Kafka会认为太缓慢并且会从同步副本列表中移除。除非replica请求leader时间间隔大于replica.lag.time.max.ms，因此即使leader使流量激增和大批量写消息。Kafka也不会从同步副本列表从移除该副本。

1.Leader Epoch引用

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

最后

分享一套我整理的面试干货，这份文档结合了我多年的面试官经验，站在面试官的角度来告诉你，面试官提的那些问题他最想听到你给他的回答是什么，分享出来帮助那些对前途感到迷茫的朋友。

面试经验技巧篇

• 经验技巧1 如何巧妙地回答面试官的问题
• 经验技巧2 如何回答技术性的问题
• 经验技巧3 如何回答非技术性问题
• 经验技巧4 如何回答快速估算类问题
• 经验技巧5 如何回答算法设计问题
• 经验技巧6 如何回答系统设计题
• 经验技巧7 如何解决求职中的时间冲突问题
• 经验技巧8 如果面试问题曾经遇见过，是否要告知面试官
• 经验技巧9 在被企业拒绝后是否可以再申请
• 经验技巧10 如何应对自己不会回答的问题
• 经验技巧11 如何应对面试官的“激将法”语言
• 经验技巧12 如何处理与面试官持不同观点这个问题
• 经验技巧13 什么是职场暗语

面试真题篇

• 真题详解1 某知名互联网下载服务提供商软件工程师笔试题
• 真题详解2 某知名社交平台软件工程师笔试题
• 真题详解3 某知名安全软件服务提供商软件工程师笔试题
• 真题详解4 某知名互联网金融企业软件工程师笔试题
• 真题详解5 某知名搜索引擎提供商软件工程师笔试题
• 真题详解6 某初创公司软件工程师笔试题
• 真题详解7 某知名游戏软件开发公司软件工程师笔试题
• 真题详解8 某知名电子商务公司软件工程师笔试题
• 真题详解9 某顶级生活消费类网站软件工程师笔试题
• 真题详解10 某知名门户网站软件工程师笔试题
• 真题详解11 某知名互联网金融企业软件工程师笔试题
• 真题详解12 国内某知名网络设备提供商软件工程师笔试题
• 真题详解13 国内某顶级手机制造商软件工程师笔试题
• 真题详解14 某顶级大数据综合服务提供商软件工程师笔试题
• 真题详解15 某著名社交类上市公司软件工程师笔试题
• 真题详解16 某知名互联网公司软件工程师笔试题
• 真题详解17 某知名网络安全公司校园招聘技术类笔试题
• 真题详解18 某知名互联网游戏公司校园招聘运维开发岗笔试题

资料整理不易，点个关注再走吧

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

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

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

• 真题详解14 某顶级大数据综合服务提供商软件工程师笔试题
• 真题详解15 某著名社交类上市公司软件工程师笔试题
• 真题详解16 某知名互联网公司软件工程师笔试题
• 真题详解17 某知名网络安全公司校园招聘技术类笔试题
• 真题详解18 某知名互联网游戏公司校园招聘运维开发岗笔试题

[外链图片转存中…(img-6hT5RnYB-1713264537079)]

资料整理不易，点个关注再走吧

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

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

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