《Kafka经典面试题 附参考答案.docx》由会员分享，可在线阅读，更多相关《Kafka经典面试题 附参考答案.docx（12页珍藏版）》请在三一办公上搜索。
1、无论是作为面试官，还是应聘者，我都接触过很多Kafka面试题。而在最近面试了很多候选人，发现写了熟悉Kafka,但是对于KaflCa相关的知识却是只知道大概用处，简单搭建和使用。我想说，虽然我们是SRE（可靠性工程师），但不论你是业务层的SRE还是基础设施层的SRE,我们都需要对业务方的使用场景有足够理解，或者对我们要提供的服务有足够的了解才行，这样你才能整体的保证你的业务连续性以及业务可靠性。因此，专门总结了如下经典的kafltopicpartition等meta数据；另外，还负责broker故障.现,partitionleader,而载均衡等功能2 .Kafka的设计时什么样的呢Kafka
2、将消息以topic为单位进行归纳将向Kafkatopic发布消息的程序成为ProdUCers.将预订topics并消费消息的程序成为consumer.Kafka以集群的方式运行，可以由一个或爹个服务组成，每个服务叫做一个broker.producers通过网络将消息发送到Kafka集群，集群向消费者提供消息。3 .为什么要使用kafka,为什么要使用消息队列？缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。解耦和扩展性：项目开始的时候，并不能确定具体
3、需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。4 .数据传输的事物定义有哪三种？数据传输的事务定义通常有以下三种级别：（1）最多一次:消息不会被重复发送，最多
4、被传输一次，但也有可能一次不传输（2）最少一次:消息不会被漏发送，最少被传输一次，但也有可能被重复传输.（3）精确的一次（EXaCtIyOnCe）:不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的5 .Kafka判断一个节点是否还活着有那两个条件？（1）节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接（2）如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久6 .Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么IsRiIn-SyncReplicas副本同步队列ARzAssign
5、edReplicas所有副本ISR是由leader维护，follower从leader同步数据有一些延迟(包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度，当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度),任意一个超过阈值都会把follower剔除出ISR,存入C)SR(Outof-SyncReplicas)列表，新加入的follower也会先存放在C)SR中。AR=ISR+0SRo7 .kafka中的broker是干什么的broker是消息的代理，Producers往Brok
6、ers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。8 .producer是否直接将数据发送到broker的Ieader(主节点)？producer直接将数据发送到broker的Ieader(主节点)，不需要在多个节点进行分发，为了帮助producer做到这点，所有的KaflCa节点都可以及时的告知:咖些节点是活动的，目标topic目标分区的Ieader在哪。这样PrOdUCer就可以直接将消息发送到目的地了9 .什么情况下一个broker会从isr中踢出去leader会维护一个与
7、其基本保持同步的Replica列表，该列表称为ISR(in-syncReplica),每个Partition都会有一个ISR,而且是由Ieader动态维护，如果一个follower比一个leader落后太多，或者超过一定时间未发起数据复制请求，则leader将其重ISR中移除。10、Kafaconsumer是否可以消费指定分区消息？Kafkaconsumer消费消息时，向broker发出fetch”请求去消费特定分区的消息，consumer指定消息在日志中的偏移量(offset),就可以消费从这个位置开始的消息，customer拥有了OffSet的控制权，可以向后回滚去重新消费之前的消息，这是
8、很有意义的HKafka消息是采用PIIn模式,还是PUSh模式?Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到COnSUmer,也就是PUIl还PUSh。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：ProdUCer将消息推送到broker,consumer从broker拉取消息一些消息系统比如Scribe和ApacheFlume采用了push模式，将消息推送到下游的COnSUmer。这样做有好处也有坏处：由broker正定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以
9、最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略PUII有个缺点是，如果broker没有
10、可供消费的消息，将导致COnSUmer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafla有个参数可以让COnSUmer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发)12 .Kafka存储在硬盘上的消息格式是什么？消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和CRC32校验码。13 消息长度4bytes(value:l+4+n)14 版本号:lbyte3CRC15 校验码:4bytes16 具体的消息:nbytes13 .Kafka高效文件存储设计特点：(1) .Kafka把topic中一个parition大文件分成多个小文
11、件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。(2).通过索引信息可以快速定位message和确定response的最大大小。(3).通过index元数据全部映射到memory,可以避免segmentfile的IO磁盘操作。(4).通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。14 .Kafka与传统消息系统之间有三个关键区别(I),Kaflca持久化日志，这些日志可以被重复读取和无限期保留(2).Kafka是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性(3).Kafka支持实时的流式处理15 .K
12、afka创建Topic时如何将分区放置到不同的Broker中(1) .副本因子不能大于Broker的个数；(2).第一个分区(编号为0)的第一个副本放置位置是随机从broker1.ist选择的;(3).其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个BrOker,5个分区，假设第一个分区放在第四个BrOker上，那么第二个分区将会放在第五个Broker上；第三个分区将会放在第一个BrokerJt；第四个分区将会放在第二个Broker上，依次类推；(4).剩余的副本相对于第一个副本放置位置其实是由nextReplicaShift决定的，而这个数也是随机产生的16 .K
13、afka新建的分区会在哪个目录下创建在启动Kafka集群之前，我们需要配置好Iogdirs参数，其值是Kafka数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。当然我们也可以配置Iogdr参数,含义样。只需要:“置.其中.个即可。如果iog.dirs参数只配置.个II#,那么分配到各个BrOker上的分区肯定只能在这个目录下创建文件夹用于存放数据。但是如果Iog.dirs参数配置了多个目录，那么Kafka会在哪个文件夹中创建分区目录呢？答案是：Kafka会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为TOPiC名十分
14、区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给Iog.dirs参数新增了一个新的磁盘,新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。17 .partition的数据如何保存到硬盘topic中的多个partition以文件夹的形式保存到broker,每个分区序号从0递增，且消息有序PartitiOn文件下有多个Segment(XXX.index,xxx.log)segment文件里的大小和配置文件大小一致可以根据要求修改默认为Ig如果大小大于Ig时，会滚动一个新的segment并且以上一个segment最后一条消
15、息的偏移量命名18、讲讲kafka维护消费状态跟踪的方法大部分消息系统在broker端的维护消息被消费的记录：一个消息被分发到consumer后broker就马上进行标记或者等待customer的通知后进行标记。这样也可以在消息在消费后立马就删除以减少空间占用。但是这样会不会有什么问题呢？如果一条消息发送出去之后就立即被标记为消费过的，一旦COnSUmer处理消息时失败了(比如程序崩溃)消息就丢失了。为了解决这个问题，很多消息系统提供了另外一个个功能：当消息被发送出去之后仅仅被标记为已发送状态，当接到ConSUmer已经消费成功的通知后才标记为已被消费的状态。这虽然解决了消息丢失的问题，但产生
16、了新问题，首先如果ConSUmer处理消息成功了但是向broker发送响应时失败了，这条消息将被消费两次。第二个问题时，broker必须维护每条消息的状态，并且每次都要先锁住消息然后更改状态然后释放锁。这样麻烦又来了，且不说要维护大量的状态数据，比如如果消息发送出去但没有收到消费成功的通知，这条消息将一直处于被锁定的状态，KaflCa采用了不同的策略。ToPiC被分成了若干分区，每个分区在同一时间只被一个ConSUmer消费。这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数：offset。这样就很容易标记每个分区消费状态就很容易了，仅仅需要一个整数而已。这样消费状态的跟踪就很简单
17、了。这带来了另外一个好处：consumer可以把OffSet调成一个较老的值，去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议，但确实是非常有用的，谁规定了一条消息只能被消费一次呢？19 .kafka的ack机制request.required.acks有三个值Ol-IO:生产者不会等待broker的ack,这个延迟最低彳旦是存需的保证最弱当SerVer挂掉的时候就会丢数据1：服务端会等待ack值leader副本确认接收到消息后发送ack但是如果leader挂掉后他不确保是否复制完成新Ieader也会导致数据丢失-1：同样在1的基础上服务端会等所有的follower的副本受到数据后
18、才会受到leader发出的ack,这样数据不会丢失20 .Kafka的消费者如何消费数据消费者每次消费数据的时候，消费者都会记录消费的物理偏移量(offset)的位置等到下次消费时，他会接着上次位置继续消费21 .消费者负载均衡策略一个消费者组中的一个分片对应一个消费者成员，他能保证每个消费者成员都能访问，如果组中成员太多会有空闲的成员22 .数据有序一个消费者组里它的内部是有序的消费者组与消费者组之间是无序的23 .kafaka生产数据时数据的分组策略生产者决定数据产生到集群的哪个partition中每一条消息都是以(key,value)格式Key是由生产者发送数据传入所以生产者(key)决定了数据产生到集群的哪个partition24 .Kafka中的消息是否会丢失和重复消费？要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。1、消息发送Kafka消息发送有两种方式：同步(SynC)和异步(async),默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.requi
