1、請(qǐng)說(shuō)明什么是Apache Kafka?

Apache Kafka是由Apache開(kāi)發(fā)的一種發(fā)布訂閱消息系統(tǒng)，它是一個(gè)分布式的、分區(qū)的和可復(fù)制的提交日志服務(wù)。

2、說(shuō)說(shuō)Kafka的使用場(chǎng)景？

①異步處理

②應(yīng)用解耦

③流量削峰

④日志處理

⑤消息通訊等。

3、使用Kafka有什么優(yōu)點(diǎn)和缺點(diǎn)？

優(yōu)點(diǎn)：

①支持跨數(shù)據(jù)中心的消息復(fù)制；

②單機(jī)吞吐量：十萬(wàn)級(jí)，最大的優(yōu)點(diǎn)，就是吞吐量高;

③topic數(shù)量都吞吐量的影響：topic從幾十個(gè)到幾百個(gè)的時(shí)候，吞吐量會(huì)大幅度下降。所以在同等機(jī)器下，kafka盡量保證topic數(shù)量不要過(guò)多。如果要支撐大規(guī)模topic，需要增加更多的機(jī)器資源;

④時(shí)效性：ms級(jí);

⑤可用性：非常高，kafka是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用;

⑥消息可靠性：經(jīng)過(guò)參數(shù)優(yōu)化配置，消息可以做到0丟失;

⑦功能支持：功能較為簡(jiǎn)單，主要支持簡(jiǎn)單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用。

缺點(diǎn)：

①由于是批量發(fā)送，數(shù)據(jù)并非真正的實(shí)時(shí)； 僅支持統(tǒng)一分區(qū)內(nèi)消息有序，無(wú)法實(shí)現(xiàn)全局消息有序；

②有可能消息重復(fù)消費(fèi)；

③依賴zookeeper進(jìn)行元數(shù)據(jù)管理，等等。

4、為什么說(shuō)Kafka性能很好，體現(xiàn)在哪里？

①順序讀寫(xiě)

②零拷貝

③分區(qū)

④批量發(fā)送

⑤數(shù)據(jù)壓縮

5、請(qǐng)說(shuō)明什么是傳統(tǒng)的消息傳遞方法?

傳統(tǒng)的消息傳遞方法包括兩種：

排隊(duì)：在隊(duì)列中，一組用戶可以從服務(wù)器中讀取消息，每條消息都發(fā)送給其中一個(gè)人。

發(fā)布-訂閱：在這個(gè)模型中，消息被廣播給所有的用戶。

6、請(qǐng)說(shuō)明Kafka相對(duì)傳統(tǒng)技術(shù)有什么優(yōu)勢(shì)?

①快速:單一的Kafka代理可以處理成千上萬(wàn)的客戶端，每秒處理數(shù)兆字節(jié)的讀寫(xiě)操作。

②可伸縮:在一組機(jī)器上對(duì)數(shù)據(jù)進(jìn)行分區(qū)

③和簡(jiǎn)化，以支持更大的數(shù)據(jù)

④持久:消息是持久性的，并在集群中進(jìn)

⑤行復(fù)制，以防止數(shù)據(jù)丟失。

⑥設(shè)計(jì):它提供了容錯(cuò)保證和持久性

7、解釋Kafka的Zookeeper是什么?我們可以在沒(méi)有Zookeeper的情況下使用Kafka嗎?

Zookeeper是一個(gè)開(kāi)放源碼的、高性能的協(xié)調(diào)服務(wù)，它用于Kafka的分布式應(yīng)用。

不，不可能越過(guò)Zookeeper，直接聯(lián)系Kafka broker。一旦Zookeeper停止工作，它就不能服務(wù)客戶端請(qǐng)求。

Zookeeper主要用于在集群中不同節(jié)點(diǎn)之間進(jìn)行通信

在Kafka中，它被用于提交偏移量，因此如果節(jié)點(diǎn)在任何情況下都失敗了，它都可以從之前提交的偏移量中獲取

除此之外，它還執(zhí)行其他活動(dòng)，如: leader檢測(cè)、分布式同步、配置管理、識(shí)別新節(jié)點(diǎn)何時(shí)離開(kāi)或連接、集群、節(jié)點(diǎn)實(shí)時(shí)狀態(tài)等等。

8、解釋Kafka的用戶如何消費(fèi)信息?

在Kafka中傳遞消息是通過(guò)使用sendfile API完成的。它支持將字節(jié)從套接口轉(zhuǎn)移到磁盤，通過(guò)內(nèi)核空間保存副本，并在內(nèi)核用戶之間調(diào)用內(nèi)核。

9、解釋如何提高遠(yuǎn)程用戶的吞吐量?

如果用戶位于與broker不同的數(shù)據(jù)中心，則可能需要調(diào)優(yōu)套接口緩沖區(qū)大小，以對(duì)長(zhǎng)網(wǎng)絡(luò)延遲進(jìn)行攤銷。

10、解釋一下，在數(shù)據(jù)制作過(guò)程中，你如何能從Kafka得到準(zhǔn)確的信息?

在數(shù)據(jù)中，為了精確地獲得Kafka的消息，你必須遵循兩件事: 在數(shù)據(jù)消耗期間避免重復(fù)，在數(shù)據(jù)生產(chǎn)過(guò)程中避免重復(fù)。

這里有兩種方法，可以在數(shù)據(jù)生成時(shí)準(zhǔn)確地獲得一個(gè)語(yǔ)義:

每個(gè)分區(qū)使用一個(gè)單獨(dú)的寫(xiě)入器，每當(dāng)你發(fā)現(xiàn)一個(gè)網(wǎng)絡(luò)錯(cuò)誤，檢查該分區(qū)中的最后一條消息，以查看您的最后一次寫(xiě)入是否成功

在消息中包含一個(gè)主鍵(UUID或其他)，并在用戶中進(jìn)行反復(fù)制

11、解釋如何減少ISR中的擾動(dòng)?broker什么時(shí)候離開(kāi)ISR?

ISR是一組與leaders完全同步的消息副本，也就是說(shuō)ISR中包含了所有提交的消息。ISR應(yīng)該總是包含所有的副本，直到出現(xiàn)真正的故障。如果一個(gè)副本從leader中脫離出來(lái)，將會(huì)從ISR中刪除。

12、Kafka為什么需要復(fù)制?

Kafka的信息復(fù)制確保了任何已發(fā)布的消息不會(huì)丟失，并且可以在機(jī)器錯(cuò)誤、程序錯(cuò)誤或更常見(jiàn)些的軟件升級(jí)中使用。

13、如果副本在ISR中停留了很長(zhǎng)時(shí)間表明什么?

如果一個(gè)副本在ISR中保留了很長(zhǎng)一段時(shí)間，那么它就表明，跟蹤器無(wú)法像在leader收集數(shù)據(jù)那樣快速地獲取數(shù)據(jù)。

14、請(qǐng)說(shuō)明如果首選的副本不在ISR中會(huì)發(fā)生什么?

如果首選的副本不在ISR中，控制器將無(wú)法將leadership轉(zhuǎn)移到首選的副本。

15、有可能在生產(chǎn)后發(fā)生消息偏移嗎?

在大多數(shù)隊(duì)列系統(tǒng)中，作為生產(chǎn)者的類無(wú)法做到這一點(diǎn)，它的作用是觸發(fā)并忘記消息。broker將完成剩下的工作，比如使用id進(jìn)行適當(dāng)?shù)脑獢?shù)據(jù)處理、偏移量等。

作為消息的用戶，你可以從Kafka

broker中獲得補(bǔ)償。如果你注視SimpleConsumer類，你會(huì)注意到它會(huì)獲取包括偏移量作為列表的MultiFetchResponse對(duì)象。此外，當(dāng)你對(duì)Kafka消息進(jìn)行迭代時(shí)，你會(huì)擁有包括偏移量和消息發(fā)送的MessageAndOffset對(duì)象。

16、Kafka的設(shè)計(jì)時(shí)什么樣的呢？

Kafka將消息以topic為單位進(jìn)行歸納

將向Kafka topic發(fā)布消息的程序成為producers. 將預(yù)訂topics并消費(fèi)消息的程序成為consumer.

Kafka以集群的方式運(yùn)行，可以由一個(gè)或多個(gè)服務(wù)組成，每個(gè)服務(wù)叫做一個(gè)broker.

producers通過(guò)網(wǎng)絡(luò)將消息發(fā)送到Kafka集群，集群向消費(fèi)者提供消息

17、數(shù)據(jù)傳輸?shù)氖挛锒x有哪三種？

（1）最多一次:

消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸

（2）最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.

（3）精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的

18、Kafka判斷一個(gè)節(jié)點(diǎn)是否還活著有那兩個(gè)條件？

（1）節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接，Zookeeper通過(guò)心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接

（2）如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫(xiě)操作，延時(shí)不能太久

19、producer是否直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))？

producer直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))，不需要在多個(gè)節(jié)點(diǎn)進(jìn)行分發(fā)，為了幫助producer做到這點(diǎn)，所有的Kafka節(jié)點(diǎn)都可以及時(shí)的告知:哪些節(jié)點(diǎn)是活動(dòng)的，目標(biāo)topic目標(biāo)分區(qū)的leader在哪。這樣producer就可以直接將消息發(fā)送到目的地了。

20、Kafa consumer是否可以消費(fèi)指定分區(qū)消息？

Kafa

consumer消費(fèi)消息時(shí)，向broker發(fā)出"fetch"請(qǐng)求去消費(fèi)特定分區(qū)的消息，consumer指定消息在日志中的偏移量（offset），就可以消費(fèi)從這個(gè)位置開(kāi)始的消息，customer擁有了offset的控制權(quán)，可以向后回滾去重新消費(fèi)之前的消息，這是很有意義的

21、Kafka消息是采用Pull模式，還是Push模式？

Kafka最初考慮的問(wèn)題是，customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push。在這方面，Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計(jì)：producer將消息推送到broker，consumer從broker拉取消息一些消息系統(tǒng)比如Scribe和Apache

Flume采用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對(duì)于不同消費(fèi)速率的consumer就不太好處理了。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費(fèi)消息，但不幸的是，push模式下，當(dāng)broker推送的速率遠(yuǎn)大于consumer消費(fèi)的速率時(shí)，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統(tǒng)的pull模式

Pull模式的另外一個(gè)好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull模式下，consumer就可以根據(jù)自己的消費(fèi)能力去決定這些策略

Pull有個(gè)缺點(diǎn)是，如果broker沒(méi)有可供消費(fèi)的消息，將導(dǎo)致consumer不斷在循環(huán)中輪詢，直到新消息到t達(dá)。為了避免這點(diǎn)，Kafka有個(gè)參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)

22、Kafka存儲(chǔ)在硬盤上的消息格式是什么？

消息由一個(gè)固定長(zhǎng)度的頭部和可變長(zhǎng)度的字節(jié)數(shù)組組成。頭部包含了一個(gè)版本號(hào)和CRC32校驗(yàn)碼。

?消息長(zhǎng)度: 4 bytes (value: 1+4+n)

?版本號(hào): 1 byte

?CRC校驗(yàn)碼: 4 bytes

?具體的消息: n bytes

23、Kafka高效文件存儲(chǔ)設(shè)計(jì)特點(diǎn)：

(1).Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段，通過(guò)多個(gè)小文件段，就容易定期清除或刪除已經(jīng)消費(fèi)完文件，減少磁盤占用。

(2).通過(guò)索引信息可以快速定位message和確定response的最大大小。

(3).通過(guò)index元數(shù)據(jù)全部映射到memory，可以避免segment file的IO磁盤操作。

(4).通過(guò)索引文件稀疏存儲(chǔ)，可以大幅降低index文件元數(shù)據(jù)占用空間大小。

24、Kafka 與傳統(tǒng)消息系統(tǒng)之間有三個(gè)關(guān)鍵區(qū)別

(1).Kafka 持久化日志，這些日志可以被重復(fù)讀取和無(wú)限期保留

(2).Kafka 是一個(gè)分布式系統(tǒng)：它以集群的方式運(yùn)行，可以靈活伸縮，在內(nèi)部通過(guò)復(fù)制數(shù)據(jù)提升容錯(cuò)能力和高可用性

(3).Kafka 支持實(shí)時(shí)的流式處理

25、Kafka創(chuàng)建Topic時(shí)如何將分區(qū)放置到不同的Broker中

?副本因子不能大于 Broker 的個(gè)數(shù)；

?第一個(gè)分區(qū)（編號(hào)為0）的第一個(gè)副本放置位置是隨機(jī)從 brokerList 選擇的；

?其他分區(qū)的第一個(gè)副本放置位置相對(duì)于第0個(gè)分區(qū)依次往后移。也就是如果我們有5個(gè)

Broker，5個(gè)分區(qū)，假設(shè)第一個(gè)分區(qū)放在第四個(gè) Broker 上，那么第二個(gè)分區(qū)將會(huì)放在第五個(gè) Broker 上；第三個(gè)分區(qū)將會(huì)放在第一個(gè)

Broker 上；第四個(gè)分區(qū)將會(huì)放在第二個(gè) Broker 上，依次類推；

?剩余的副本相對(duì)于第一個(gè)副本放置位置其實(shí)是由 nextReplicaShift 決定的，而這個(gè)數(shù)也是隨機(jī)產(chǎn)生的

26、Kafka新建的分區(qū)會(huì)在哪個(gè)目錄下創(chuàng)建

在啟動(dòng)

Kafka 集群之前，我們需要配置好 log.dirs 參數(shù)，其值是 Kafka

數(shù)據(jù)的存放目錄，這個(gè)參數(shù)可以配置多個(gè)目錄，目錄之間使用逗號(hào)分隔，通常這些目錄是分布在不同的磁盤上用于提高讀寫(xiě)性能。 當(dāng)然我們也可以配置

log.dir 參數(shù)，含義一樣。只需要設(shè)置其中一個(gè)即可。 如果 log.dirs 參數(shù)只配置了一個(gè)目錄，那么分配到各個(gè) Broker

上的分區(qū)肯定只能在這個(gè)目錄下創(chuàng)建文件夾用于存放數(shù)據(jù)。 但是如果 log.dirs 參數(shù)配置了多個(gè)目錄，那么 Kafka

會(huì)在哪個(gè)文件夾中創(chuàng)建分區(qū)目錄呢？答案是：Kafka 會(huì)在含有分區(qū)目錄最少的文件夾中創(chuàng)建新的分區(qū)目錄，分區(qū)目錄名為

Topic名+分區(qū)ID。注意，是分區(qū)文件夾總數(shù)最少的目錄，而不是磁盤使用量最少的目錄！也就是說(shuō)，如果你給 log.dirs

參數(shù)新增了一個(gè)新的磁盤，新的分區(qū)目錄肯定是先在這個(gè)新的磁盤上創(chuàng)建直到這個(gè)新的磁盤目錄擁有的分區(qū)目錄不是最少為止。

27、partition的數(shù)據(jù)如何保存到硬盤

topic中的多個(gè)partition以文件夾的形式保存到broker，每個(gè)分區(qū)序號(hào)從0遞增，

且消息有序 Partition文件下有多個(gè)segment（xxx.index，xxx.log） segment 文件里的

大小和配置文件大小一致可以根據(jù)要求修改 默認(rèn)為1g

如果大小大于1g時(shí)，會(huì)滾動(dòng)一個(gè)新的segment并且以上一個(gè)segment最后一條消息的偏移量命名

28、kafka的ack機(jī)制

request.required.acks有三個(gè)值 0 1 -1

0:生產(chǎn)者不會(huì)等待broker的ack，這個(gè)延遲最低但是存儲(chǔ)的保證最弱當(dāng)server掛掉的時(shí)候就會(huì)丟數(shù)據(jù)

1：服務(wù)端會(huì)等待ack值 leader副本確認(rèn)接收到消息后發(fā)送ack但是如果leader掛掉后他不確保是否復(fù)制完成新leader也會(huì)導(dǎo)致數(shù)據(jù)丟失

-1：同樣在1的基礎(chǔ)上 服務(wù)端會(huì)等所有的follower的副本受到數(shù)據(jù)后才會(huì)受到leader發(fā)出的ack，這樣數(shù)據(jù)不會(huì)丟失

29、Kafka的消費(fèi)者如何消費(fèi)數(shù)據(jù)

消費(fèi)者每次消費(fèi)數(shù)據(jù)的時(shí)候，消費(fèi)者都會(huì)記錄消費(fèi)的物理偏移量（offset）的位置 等到下次消費(fèi)時(shí)，他會(huì)接著上次位置繼續(xù)消費(fèi)。同時(shí)也可以按照指定的offset進(jìn)行重新消費(fèi)。

30、消費(fèi)者負(fù)載均衡策略

結(jié)合consumer的加入和退出進(jìn)行再平衡策略。

31、kafka消息數(shù)據(jù)是否有序？

消費(fèi)者組里某具體分區(qū)是有序的，所以要保證有序只能建一個(gè)分區(qū)，但是實(shí)際這樣會(huì)存在性能問(wèn)題，具體業(yè)務(wù)具體分析后確認(rèn)。

32、kafaka生產(chǎn)數(shù)據(jù)時(shí)數(shù)據(jù)的分組策略,生產(chǎn)者決定數(shù)據(jù)產(chǎn)生到集群的哪個(gè)partition中

每一條消息都是以（key，value）格式 Key是由生產(chǎn)者發(fā)送數(shù)據(jù)傳入 所以生產(chǎn)者（key）決定了數(shù)據(jù)產(chǎn)生到集群的哪個(gè)partition

33、kafka consumer 什么情況會(huì)觸發(fā)再平衡reblance?

①一旦消費(fèi)者加入或退出消費(fèi)組，導(dǎo)致消費(fèi)組成員列表發(fā)生變化，消費(fèi)組中的所有消費(fèi)者都要執(zhí)行再平衡。

②訂閱主題分區(qū)發(fā)生變化，所有消費(fèi)者也都要再平衡。

34、描述下kafka consumer 再平衡步驟?

①關(guān)閉數(shù)據(jù)拉取線程，情空隊(duì)列和消息流，提交偏移量；

②釋放分區(qū)所有權(quán)，刪除zk中分區(qū)和消費(fèi)者的所有者關(guān)系；

③將所有分區(qū)重新分配給每個(gè)消費(fèi)者，每個(gè)消費(fèi)者都會(huì)分到不同分區(qū)；

④將分區(qū)對(duì)應(yīng)的消費(fèi)者所有關(guān)系寫(xiě)入ZK，記錄分區(qū)的所有權(quán)信息；

⑤重啟消費(fèi)者拉取線程管理器，管理每個(gè)分區(qū)的拉取線程。

以上Kafka面試題部分來(lái)自網(wǎng)絡(luò)，答案僅供參考，如果有不同的看法可以留言討論。死記硬背的方式不建議。如果您最近有面試到關(guān)于Kafka的面試題，歡迎留言分享哦~

下面這份是我找到的另一篇Kafka面試資料，有需要的話點(diǎn)贊+關(guān)注，私信我就能獲取啦！