Kafka大厂面试14问(附答案)

怎么保证顺序消费?

同一个生产者发送到同一分区的消息,先发送的比后发送的offset要小。同一生产者发送到不同分区的消息,消息顺序无法保证。

怎么解决这个问题?

给一个topic只设置一个分区

相同key会发给一个分区

怎么保证幂等性?

**生产者:**如果发生网络抖动等导致ack返回超时,可以通过producer Id + sequence Number,每个producer在初始化时都会有唯一的pid,对每个生产者发送到分区中的消息都会对应一个从0递增的sequence Number,这样分区接收到消息的时候就能判断sequenceNumber是否重复

消费者 :比如设置了手动提交offset,消息已经拉取消费了但是还没提交就挂了,可能会导致重复拉取同一段消息。用redis 分布式锁 或者根据业务判断该消息是否被消费过

kafka 消息丢失?

生产者:

Ack = 0,表示不需要等待任何broker回复,可能会在发送到broker或者fl同步的时候丢消息

Ack = 1,表示等待master回复,可能发送到ld还没来得及同步到follwer,master就挂了,导致消息丢失

Ack = -1,等ld和isr中的fl都收到消息,才发送ack

消费者:

设置的自动提交offset,消息拉取了,但是没消费完,就提交了offset,但是消费者宕机了;

另外在ld选举的时候,zk中会维护isr(已同步ld数据)和osr(未同步ld数据)中选举,配置设置为true的时候,如果isr没有数据就会从osr选举

解决:

  • 配置ack为-1或者all

  • 不允许选举isr以外的副本作为ld

  • 可以设置最小同步数量>1,如果不满足则生产者端会抛异常

  • 减少broker的刷盘间隔

线上消息积压怎么解决?

  1. 生产者发送消息过快,消费者消费慢 -> 如果需要紧急处理,可以把修改消费端程序,让它将收到的消息快速转发到其他topic,然后启动多个消费者同时消费新主题的不同分区

  2. 消息数据格式变动,导致一直消费不成功,也可能导致消息积压,可以转发到死信队列

不同 消息队列 的优缺点?

rabbitmq:erlang语言,性能好,支持高并发,不利于二次开发

kafka:java实现,高性能高可用,适用于大数据量场景,单机吞吐量百万,缺点单机容量有限

rocketmq:java实现,方便二次开发,高可用高可靠,单机吞吐量十万

kafka 高性能高吞吐的原因?

  1. 磁盘的顺序读写(随机读写的话会多次寻址和旋转),而且会预读一些放在内存中

  2. 零拷贝:传统是先读取磁盘空间到内核缓冲区,然后到用户缓冲区,再到socket发送缓冲区;零拷贝是直接从内核缓冲区到socket发送缓冲区,避免了内核态和用户态的切换

  3. 分区分段:每一个分区都是很多个segment文件,针对这些文件有索引,可以快速查找

  4. 批量压缩,批量读写:比如发送消息的时候是异步发送,当发送一条消息时不会直接发送给broker,而是会先缓存起来,然后批量发送,减少io

  5. **页缓存:**在缓存中操作数据,比在磁盘操作更快

zk 的作用?

老版本中,broker会在zookeeper上注册,创建唯一临时节点,并定时发送心跳到zk,如果心跳断开则剔除。接待拿下存储了topic和分区相关信息,维护了消费者组和分区的注册关系以及offset

新版本中可以不使用zookeeper,使用kraft组件,offset由消费者自己维护

kafka 副本数据一致性?

hw:分区的ld和fl共同持有的消息,消费者只能消费hw之前的值

leo:每个分区节点已经存在的消息数

从节点出现故障时,把故障节点剔除isr,如果故障恢复了,会将hw之后的消息删除,然后重新从主节点中同步现在的数据

主节点出现故障:选取出来主节点之后,其他从节点会把大于hw值的消息丢掉,然后重新从主节点同步数据

Kafka 的rebalance机制?

比如你要向消费者组中新增一个消费者,需要把消费者和对应的topic分区进行匹配,就会产生rebalance,场景主要有:

  • 消费者组的成员个数发生变化

  • group订阅的topic个数发生变化

  • group订阅的topic分区数发生变化

ld所在的broker就是一个协调者,通过心跳机制监控消费者组中consumer的存活,返回通知消费者进行balance,选举出新的ld consumer ,ldconsumer从协调者获取所有的consumer,将分配信息发给协调者,协调者再通过心跳机制下发给consumer

读写会进行阻塞,所以要尽量避免rebalance

消费者分区分配策略?

Range 范围分区(默认):比如一人领走几个

轮询:给你一个给你一个再转一圈

sticky:粘性

使用这个消费者组中使用最多的分配策略

分区和 消费者组 的对应关系?

一个消费者组相当于是一个订阅者,可以订阅主题,然后这些消费者共同消费主题下的分区。当消费者小于分区数时,一个消费者可以消费多个分区;当消费者大于分区数时,可能有消费者空闲(一个分区只能被同一消费者组里的一个消费者消费)

kafka 的高可用机制?

集群机制:一个kafka集群由多个broker组成,即使某一个broker宕机也不会影响其他的broker

分区备份机制:一个分区可能会存在多个副本,这些副本存储在不同的broker上。如果ld的副本宕机,就会从isr中的follower中选举出一个新的ld,因为isr是同步复制数据,准确性较高;如果没有可用的isr,就会从osr中选举

kafka 的数据清理机制?

kafka的topic数据存储在分区上,分区如果文件过大会分段存储,并且有对应的索引文件和日志文件,这样做能减少单个文件的大小,方便查找数据和日志清理

kafka清理数据有两种策略:第一是根据消息的保留时间,默认超过7天清理;第二是根据存储数据的大小,超过一定阈值就会删除最久的消息(默认关闭)。

如有问题,欢迎指正!

相关推荐
Data跳动2 小时前
Spark内存都消耗在哪里了?
大数据·分布式·spark
Java程序之猿3 小时前
微服务分布式(一、项目初始化)
分布式·微服务·架构
来一杯龙舌兰4 小时前
【RabbitMQ】RabbitMQ保证消息不丢失的N种策略的思想总结
分布式·rabbitmq·ruby·持久化·ack·消息确认
GISer_Jing4 小时前
2025前端面试热门题目——计算机网络篇
前端·计算机网络·面试
m0_748245524 小时前
吉利前端、AI面试
前端·面试·职场和发展
节点。csn6 小时前
Hadoop yarn安装
大数据·hadoop·分布式
TodoCoder6 小时前
【编程思想】CopyOnWrite是如何解决高并发场景中的读写瓶颈?
java·后端·面试
saynaihe7 小时前
安全地使用 Docker 和 Systemctl 部署 Kafka 的综合指南
运维·安全·docker·容器·kafka
Wyang_XXX7 小时前
CSS 选择器和优先级权重计算这么简单,你还没掌握?一篇文章让你轻松通关面试!(下)
面试
NiNg_1_2347 小时前
基于Hadoop的数据清洗
大数据·hadoop·分布式