Kafka常見面試題解答
1.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)代表什么？
ISR : 速率和leader相差低于10秒的follower的集合 OSR : 速率和leader相差大于10秒的follower AR : 所有分區(qū)的follower
2.Kafka中的HW、LEO等分別代表什么？
HW : 又名高水位,根據(jù)同一分區(qū)中,最低的LEO所決定 LEO : 每個分區(qū)的最高offset
3.Kafka的用途有哪些？使用場景如何？
用戶追蹤:根據(jù)用戶在web或者app上的操作,將這些操作消息記錄到各個topic中,然后消費(fèi)者通過訂閱這些消息做實時的分析,或者記錄到HDFS,用于離線分析或數(shù)據(jù)挖掘 日志收集:通過kafka對各個服務(wù)的日志進(jìn)行收集,再開放給各個consumer 消息系統(tǒng):緩存消息 運(yùn)營指標(biāo):記錄運(yùn)營監(jiān)控數(shù)據(jù),收集操作應(yīng)用數(shù)據(jù)的集中反饋,如報錯和報告
4.Kafka中是怎么體現(xiàn)消息順序性的？
每個分區(qū)內(nèi),每條消息都有offset,所以只能在同一分區(qū)內(nèi)有序,但不同的分區(qū)無法做到消息順序性
5.“消費(fèi)組中的消費(fèi)者個數(shù)如果超過topic的分區(qū)，那么就會有消費(fèi)者消費(fèi)不到數(shù)據(jù)”這句話是否正確?
對的,超過分區(qū)數(shù)的消費(fèi)者就不會再接收數(shù)據(jù)
6.有哪些情形會造成重復(fù)消費(fèi)？或丟失信息?
先處理后提交offset,會造成重讀消費(fèi) 先提交offset后處理,會造成數(shù)據(jù)丟失
7.Kafka 分區(qū)的目的？
對于kafka集群來說,分區(qū)可以做到負(fù)載均衡,對于消費(fèi)者來說,可以提高并發(fā)度,提高讀取效率。
8.Kafka 的高可靠性是怎么實現(xiàn)的?
為了實現(xiàn)高可靠性,kafka使用了訂閱的模式,并使用isr和ack應(yīng)答機(jī)制，能進(jìn)入isr中的follower和leader之間的速率不會相差10秒
當(dāng)ack=0時,producer不等待broker的ack,不管數(shù)據(jù)有沒有寫入成功,都不再重復(fù)發(fā)該數(shù)據(jù) 當(dāng)ack=1時,broker會等到leader寫完數(shù)據(jù)后,就會向producer發(fā)送ack,但不會等follower同步數(shù)據(jù),如果這時leader掛掉,producer會對新的leader發(fā)送新的數(shù)據(jù),在old的leader中不同步的數(shù)據(jù)就會丟失 當(dāng)ack=-1或者all時,broker會等到leader和isr中的所有follower都同步完數(shù)據(jù),再向producer發(fā)送ack,有可能造成數(shù)據(jù)重復(fù)
9.topic的分區(qū)數(shù)可不可以增加？如果可以怎么增加？如果不可以，那又是為什么？
可以增加
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3
10.topic的分區(qū)數(shù)可不可以減少？如果可以怎么減少？如果不可以，那又是為什么？
不可以,先有的分區(qū)數(shù)據(jù)難以處理
11.簡述Kafka的日志目錄結(jié)構(gòu)？
每一個分區(qū)對應(yīng)一個文件夾,命名為topic-0,topic-1,每個文件夾內(nèi)有.index和.log文件
12.如何解決消費(fèi)者速率低的問題?
增加分區(qū)數(shù)和消費(fèi)者數(shù)
13.Kafka的那些設(shè)計讓它有如此高的性能？?
kafka是分布式的消息隊列 對log文件進(jìn)行了segment,并對segment建立了索引 (對于單節(jié)點(diǎn))使用了順序讀寫,速度可以達(dá)到600M/s 引用了zero拷貝,在os系統(tǒng)就完成了讀寫操作
14.kafka啟動不起來的原因?
在關(guān)閉kafka時,先關(guān)了zookeeper,就會導(dǎo)致kafka下一次啟動時,會報節(jié)點(diǎn)已存在的錯誤
只要把zookeeper中的zkdata/version-2的文件夾刪除即可
15.聊一聊Kafka Controller的作用？
負(fù)責(zé)kafka集群的上下線工作,所有topic的副本分區(qū)分配和選舉leader工作
16.Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？
在ISR中需要選擇,選擇策略為先到先得
17.失效副本是指什么？有那些應(yīng)對措施？
失效副本為速率比leader相差大于10秒的follower 將失效的follower先提出ISR 等速率接近leader10秒內(nèi),再加進(jìn)ISR
18.Kafka消息是采用Pull模式，還是Push模式？
在producer階段,是向broker用Push模式 在consumer階段,是向broker用Pull模式
在Pull模式下,consumer可以根據(jù)自身速率選擇如何拉取數(shù)據(jù),避免了低速率的consumer發(fā)生崩潰的問題
但缺點(diǎn)是,consumer要時不時的去詢問broker是否有新數(shù)據(jù),容易發(fā)生死循環(huán),內(nèi)存溢出。
學(xué)習(xí)資料：Java進(jìn)階視頻資源
19.Kafka創(chuàng)建Topic時如何將分區(qū)放置到不同的Broker中?
首先副本數(shù)不能超過broker數(shù)
第一分區(qū)是隨機(jī)從Broker中選擇一個,然后其他分區(qū)相對于0號分區(qū)依次向后移 第一個分區(qū)是從nextReplicaShift決定的,而這個數(shù)也是隨機(jī)產(chǎn)生的
20.Kafka中的事務(wù)是怎么實現(xiàn)的?☆☆☆☆☆
kafka事務(wù)有兩種:
producer事務(wù)和consumer事務(wù)
producer事務(wù)是為了解決kafka跨分區(qū)跨會話問題，kafka不能跨分區(qū)跨會話的主要問題是每次啟動的producer的PID都是系統(tǒng)隨機(jī)給的
所以為了解決這個問題，我們就要手動給producer一個全局唯一的id,也就是transaction id 簡稱TID
我們將TID和PID進(jìn)行綁定,在producer帶著TID和PID第一次向broker注冊時,broker就會記錄TID,并生成一個新的組件transaction_state用來保存TID的事務(wù)狀態(tài)信息。當(dāng)producer重啟后,就會帶著TID和新的PID向broker發(fā)起請求,當(dāng)發(fā)現(xiàn)TID一致時，producer就會獲取之前的PID,將覆蓋掉新的PID,并獲取上一次的事務(wù)狀態(tài)信息,從而繼續(xù)上次工作
consumer事務(wù)相對于producer事務(wù)就弱一點(diǎn),需要先確保consumer的消費(fèi)和提交位置為一致且具有事務(wù)功能,才能保證數(shù)據(jù)的完整,不然會造成數(shù)據(jù)的丟失或重復(fù)
21.Kafka中的分區(qū)器、序列化器、攔截器是否了解？它們之間的處理順序是什么？
攔截器>序列化器>分區(qū)器
22.Kafka生產(chǎn)者客戶端的整體結(jié)構(gòu)是什么樣子的？使用了幾個線程來處理？分別是什么？
使用兩個線程:
main線程和sender線程
main線程會依次經(jīng)過攔截器,序列化器,分區(qū)器將數(shù)據(jù)發(fā)送到RecourdAccumlator(線程共享變量)。再由sender線程從RecourdAccumlator中拉取數(shù)據(jù)發(fā)送到kafka broker
相關(guān)參數(shù)：
batch.size：只有數(shù)據(jù)積累到batch.size之后，sender才會發(fā)送數(shù)據(jù)。 linger.ms：如果數(shù)據(jù)遲遲未達(dá)到batch.size，sender等待linger.time之后就會發(fā)送數(shù)據(jù)。
23.消費(fèi)者提交消費(fèi)位移時提交的是當(dāng)前消費(fèi)到的最新消息的offset還是offset+1？
offset + 1
圖示:
生產(chǎn)者發(fā)送數(shù)據(jù)offset是從0開始的
消費(fèi)者消費(fèi)的數(shù)據(jù)offset是從offset+1開始的
來源：blog.csdn.net/C_Xiang_Falcon/
article/details/100917145
轉(zhuǎn)自：Java知音