Kafka经典面试题 附参考答案.docx

《Kafka经典面试题 附参考答案.docx》由会员分享，可在线阅读，更多相关《Kafka经典面试题 附参考答案.docx（12页珍藏版）》请在优知文库上搜索。

1、无论是作为面试官，还是应聘者，我都接触过很多Kafka面试题。而在最近面试了很多候选人，发现写了熟悉Kafka,但是对于KaflCa相关的知识却是只知道大概用处，简单搭建和使用。我想说，虽然我们是SRE（可靠性工程师），但不论你是业务层的SRE还是基础设施层的SRE,我们都需要对业务方的使用场景有足够理解，或者对我们要提供的服务有足够的了解才行，这样你才能整体的保证你的业务连续性以及业务可靠性。因此，专门总结了如下经典的kafla面试详解。以下面试题，参考胡夕胡大的Kafka核心源码解读，对相关的知识进行了补充和思考。基础题目ApacheKafka是什么？能问这道题，主要是想看候选人对于Kaf

2、ka的使用场景以及定位认知理解有多深，同时候可以知道候选人对于这项技术的关注度。我们都知道，在开源软件中，大部分软件随着用户量的增加，整个软件的功能和定位也有了新的变化，而APaCheKafka一路发展到现在，已经由最初的分布式提交日志系统逐渐演变成了实时流处理框架。因此，这道题你最好这么回答：ApachKafka是一款分布式流处理平台，用于实时构建流处理应用。它有一个核心的功能广为人知，即作为企业级的消息引擎被广泛使用（通常也会称之为消息总线messagebus）o关于分布式流处理平台，其实从它官方的1.ogo以及Slogan我们就很容易看出来。什么是消费者组？消费者组是Kafka独有的概念

3、，如果面试官问这个，就说明他对此是有一定了解的。胡大给的标准答案是：官网上的介绍言简意赅，即消费者组是Kafka提供的可扩展且具有容错性的消费者机制。但实际上，消费者组（ConSUmerGroUP）其实包含两个概念，作为队列，消费者组允许你分割数据处理到一组进程集合上（即一个消费者组中可以包含多个消费者进程,他们共同消费该t。PiC的数据）,这有助于你的消费能力的动态调整;作为发布-订阅模型（PUbliSh-SUbSCribe）,Kafka允许你将同一份消息广播到多个消费者组里，以此来丰富多种数据使用场景。需要注意的是：在消费者组中，多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实

4、例都配置有相同的组ID,被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起它负责消费的分区。因此，消费者组在一定程度上也保证了消费者程序的高可用性。KafkaCluster-Server1-pServer2PP3p1P2/X、/注意：消费者组的题目，能够帮你在某种程度上掌控下面的面试方向。如果你擅长位移值原理(OffSet),就不妨再提一下消费者组的位移提交机制；如果你擅长KafkaBroker,可以提一下消费者组与BrOker之间的交互；如果你擅长与消费者组完全不相关的Producer,那么就可以这么说：“消费者组要消费的数据完全来自于ProdUCer端生产的消息，我对PrO

5、dUCer还是比较熟悉的。”总之，你总得对ConSUmergrOUP相关的方向有一定理解，然后才能像面试官表名你对某一块很理解。在Kafka中，ZooKeeper的作用是什么？这道题，也是我经常会问候选人的题，因为任何分布式系统中虽然都通过一些列的算法去除了传统的关系型数据存储，但是毕竟还是有些数据要存储的，同时分布式系统的特性往往是需要有一些中间人角色来统筹集群。比如我们在整个微服务框架中的Dubbo,它也是需要依赖一些注册中心或配置中心类的中间件的，以及云原生的Kubernetes使用etcd作为整个集群的枢纽。标准答案：目前,Kafka使用ZOoKeePer存放集群元数据、成员管理、CO

6、ntrOlIer选举，以及其他一些管理类任务。之后，等KIP-500提案完成后，Kafka将完全不再依赖于ZooKeeper0“存放元数据”是指主题分区的所有数据都保存在ZOOKeePer中，且以它保存的数据为权威,其他“人都要与它保持对齐。“成员管理”是指Broker节点的注册、注销以及属性变更，等等。“ContIer选举”是指选举集群COnglIer,而其他管理类任务包括但不限于主题删除、参数配置等。KIP-500思想，是使用社区自研的基于Raft的共识算法，替代ZOOKeeper,实现Controller自选举。解释下Kafka中位移(offset)的作用标准答案：在Kaflca中，每个

7、主题分区下的每条消息都被赋予了一个唯一的ID数值，用于标识它在分区中的位置。这个ID数值，就被称为位移，或者叫偏移量。一旦消息被写入到分区日志，它的位移值将不能被修改。答完这些之后，你还可以把整个面试方向转移到你希望的地方：如果你深谙BrOker底层日志写入的逻辑，可以强调下消息在日志中的存放格式如果你明白位移值一旦被确定不能修改，可以强调下“1.ogCleaner组件都不能影响位移值”这件事情如果你对消费者的概念还算熟悉，可以再详细说说位移值和消费者位移值之间的区别阐述下Kafka中的领导者副本(1.eaderReplica)和追随者副本(FollowerReplica)的区别推荐的答案：K

8、afka副本当前分为领导者副本和追随者副本。只有1.eader副本才能对外提供读写服务，响应Clients端的请求。Follower副本只是采用拉(PU1.1.)的方式，被动地同步1.eader副本中的数据，并且在1.eader副本所在的Broker宕机后，随时准备应聘1.eader副本。加分点：强调FollOWer副本也能对外提供读服务。自Kafka2.4版本开始，社区通过引入新的Broker端参数，允许Follower副本有限度地提供读服务。强调1.eader和Follower的消息序列在实际场景中不一致。通常情况下，很多因素可能造成1.eader和Follower之间的不同步，比如程序问

9、题，网络问题，broker问题等，短暂的不同步我们可以关注(秒级别)，但长时间的不同步可能就需要深入排查了，因为一旦1.eader所在节点异常，可能直接影响可用性。注意：之前确保一致性的主要手段是高水位机制(HW),但高水位值无法保证1.eader连续变更场景下的数据一致性，因此,社区引入了1.eaderEpoch机制，来修复高水位值的弊端。实操题目如何设置Kafka能接收的最大消息的大小？对于SRE来讲，该题简直是送分题啊，但是，最大消息的设置通常情况下有生产者端，消费者端，broker端和topic级别的参数，我们需要正确设置，以保证可以正常的生产和消费。Broker端参数：message

10、.max.bytes,max.message.bytes(topic级另J),replica.fetch.max.bytes(否则follow会同步失败)Consumer端参数：fetch.message.max.bytes监控Kafka的框架都有哪些？对于SRE来讲，依然是送分题。但基础的我们要知道，Kafka本身是提供了JMX(JavaManagementExtensions)的，我们可以通过它来获取到Kafka内部的一些基本数据。KafkaManager:更多是Kafka的管理，对于SRE非常友好，也提供了简单的瞬时指标监控。KafkaMonitor:1.inkedln开源的免费框架，支

11、持对集群进行系统测试，并实时监控测试结果。CruiseControl:也是1.inkedln公司开源的监控框架，用于实时监测资源使用率，以及提供常用运维操作等。无Ul界面，只提供RESTAPI,可以进行多集群管理。JMX监控：由于Kafka提供的监控指标都是基于JMX的，因此，市面上任何能够集成JMX的框架都可以使用，比如Zabbix和Prometheuso已有大数据平台自己的监控体系:像Cloudera提供的CDH这类大数据平台，天然就提供Kafka监控方案。JMXTooI:社区提供的命令行工具，能够实时监控JMX指标。可以使用kafka-run-class.shkafka.tools.Jm

12、xTool来查看具体的用法。Broker的HeapSize如何设置？其实对于SRE还是送分题，因为目前来讲大部分公司的业务系统都是使用JaVa开发，因此SRE对于基本的JVM相关的参数应该至少都是非常了解的，核心就在于JVM的配置以及GC相关的知识。标准答案:任何Java进程JVM堆大小的设置都需要仔细地进行考量和测试。一个常见的做法是，以默认的初始JVM堆大小运行程序，当系统达到稳定状态后，手动触发一次FUnGe然后通过JVM工具查看Ge后的存活对象大小。之后，将堆大小设置成存活对象总大小的1.52倍。对于Kafka而言，这个方法也是适用的。不过，业界有个最佳实践，那就是将Broker的He

13、aPSiZe固定为6GB。经过很多公司的验证，这个大小是足够且良好的。如何估算Kafka集群的机器数量？该题也算是SRE的送分题吧，对于SRE来讲，任何生产的系统第一步需要做的就是容量预估以及集群的架构规划，实际上也就是机器数量和所用资源之间的关联关系，资源通常来讲就是CPU,内存，磁盘容量，带宽。但需要注意的是，Kafka因为独有的设计，对于磁盘的要求并不是特别高，普通机械硬盘足够，而通常的瓶颈会出现在带宽上。在预估磁盘的占用时，你一定不要忘记计算副本同步的开销。如果一条消息占用IKB的磁盘空间，那么，在有3个副本的主题中，你就需要3KB的总空间来保存这条消息。同时，需要考虑到整个业务TOP

14、iC数据保存的最大时间，以上几个因素，基本可以预估出来磁盘的容量需求。需要注意的是：对于磁盘来讲，一定要提前和业务沟通好场景，而不是等待真正有磁盘容量瓶颈了才去扩容磁盘或者找业务方沟通方案。对于带宽来说，常见的带宽有IGbPS和IOGbPs,通常我们需要知道，当带宽占用接近总带宽的90%时，丢包情形就会发生。1.eader总是-1,怎么破？对于有经验的SRE来讲，早期的Kafka版本应该多多少少都遇到过该种情况，通常情况下就是COntrOner不工作了，导致无法分配Ieader,那既然知道问题后，解决方案也就很简单了。重启COntrOner节点上的Kafka进程，让其他节点重新注册Contro

15、ller角色，但是如上面ZooKeeper的作用，你要知道为什么Controller可以自动注册。当然了，当你知道COntrolIer的注册机制后，你也可以说：删除ZooKe叩er节点/controller,触发Controller重选举。Controller重选举能够为所有主题分区重刷分区状态，可以有效解决因不一致导致的1.eader不可用问题。但是，需要注意的是，直接操作ZOOKe叩er是一件风险很大的操作，就好比在1.inUX中执行了ITn-rf/xxx一样，如果在/和XXX之间不小心多了几个空格，那恭喜你，今年白干了O炫技式题目1.EO、1.S0、AR、ISR、HW都表示什么含义？讲真

16、，我不认为这是炫技的题目，特别是作为SRE来讲，对于一个开源软件的原理以及概念的理解，是非常重要的。1.EO(1.ogEndOffset):日志末端位移值或末端偏移量，表示日志下一条待插入消息的位移值。举个例子，如果日志有10条消息，位移值从0开始，那么，第10条消息的位移值就是9。此时，1.EO=1001.SO(1.ogStabIeOffset):这是Kafka事务的概念。如果你没有使用到事务，那么这个值不存在(其实也不是不存在，只是设置成一个无意义的值)。该值控制了事务型消费者能够看到的消息范围。它经常与1.ogStartOffset,即日志起始位移值相混淆，因为有些人将后者缩写成1.SO,这是不对的。在Kafka中，1.SO就是指代1.ogStableOffsetoAR(