Kafka相關(guān)面試題有哪些

本篇內(nèi)容主要講解“Kafka相關(guān)面試題有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Kafka相關(guān)面試題有哪些”吧!

堅(jiān)守“ 做人真誠(chéng) · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價(jià)值觀，專業(yè)網(wǎng)站建設(shè)服務(wù)10余年為成都成都玻璃鋼坐凳小微創(chuàng)業(yè)公司專業(yè)提供成都企業(yè)網(wǎng)站定制營(yíng)銷網(wǎng)站建設(shè)商城網(wǎng)站建設(shè)手機(jī)網(wǎng)站建設(shè)小程序網(wǎng)站建設(shè)網(wǎng)站改版，從內(nèi)容策劃、視覺設(shè)計(jì)、底層架構(gòu)、網(wǎng)頁(yè)布局、功能開發(fā)迭代于一體的高端網(wǎng)站建設(shè)服務(wù)。

1. 為什么要使用 kafka？

1. 緩沖和削峰：上游數(shù)據(jù)時(shí)有突發(fā)流量，下游可能扛不住，或者下游沒有足夠多的機(jī)器來保證冗余，kafka在中間可以起到一個(gè)緩沖的作用，把消息暫存在kafka中，下游服務(wù)就可以按照自己的節(jié)奏進(jìn)行慢慢處理。

2. 解耦和擴(kuò)展性：項(xiàng)目開始的時(shí)候，并不能確定具體需求。消息隊(duì)列可以作為一個(gè)接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對(duì)數(shù)據(jù)編程即可獲取擴(kuò)展能力。

3. 冗余：可以采用一對(duì)多的方式，一個(gè)生產(chǎn)者發(fā)布消息，可以被多個(gè)訂閱topic的服務(wù)消費(fèi)到，供多個(gè)毫無關(guān)聯(lián)的業(yè)務(wù)使用。

4. 健壯性：消息隊(duì)列可以堆積請(qǐng)求，所以消費(fèi)端業(yè)務(wù)即使短時(shí)間死掉，也不會(huì)影響主要業(yè)務(wù)的正常進(jìn)行。

5. 異步通信：很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。

2. Kafka消費(fèi)過的消息如何再消費(fèi)？

kafka消費(fèi)消息的offset是定義在zookeeper中的， 如果想重復(fù)消費(fèi)kafka的消息，可以在redis中自己記錄offset的checkpoint點(diǎn)（n個(gè)），當(dāng)想重復(fù)消費(fèi)消息時(shí)，通過讀取redis中的checkpoint點(diǎn)進(jìn)行zookeeper的offset重設(shè)，這樣就可以達(dá)到重復(fù)消費(fèi)消息的目的了

3. kafka的數(shù)據(jù)是放在磁盤上還是內(nèi)存上，為什么速度會(huì)快？

kafka使用的是磁盤存儲(chǔ)。

速度快是因?yàn)椋?/p>

1. 順序?qū)懭耄阂驗(yàn)橛脖P是機(jī)械結(jié)構(gòu)，每次讀寫都會(huì)尋址->寫入，其中尋址是一個(gè)“機(jī)械動(dòng)作”，它是耗時(shí)的。所以硬盤 “討厭”隨機(jī)I/O， 喜歡順序I/O。為了提高讀寫硬盤的速度，Kafka就是使用順序I/O。

2. Memory Mapped Files（內(nèi)存映射文件）：64位操作系統(tǒng)中一般可以表示20G的數(shù)據(jù)文件，它的工作原理是直接利用操作系統(tǒng)的Page來實(shí)現(xiàn)文件到物理內(nèi)存的直接映射。完成映射之后你對(duì)物理內(nèi)存的操作會(huì)被同步到硬盤上。

3. Kafka高效文件存儲(chǔ)設(shè)計(jì)： Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段，通過多個(gè)小文件段，就容易定期清除或刪除已經(jīng)消費(fèi)完文件，減少磁盤占用。通過索引信息可以快速定位
   message和確定response的 大 小。通過index元數(shù)據(jù)全部映射到memory（內(nèi)存映射文件），
   可以避免segment file的IO磁盤操作。通過索引文件稀疏存儲(chǔ)，可以大幅降低index文件元數(shù)據(jù)占用空間大小。

注：

1. Kafka解決查詢效率的手段之一是將數(shù)據(jù)文件分段，比如有100條Message，它們的offset是從0到99。假設(shè)將數(shù)據(jù)文件分成5段，第一段為0-19，第二段為20-39，以此類推，每段放在一個(gè)單獨(dú)的數(shù)據(jù)文件里面，數(shù)據(jù)文件以該段中 小的offset命名。這樣在查找指定offset的
   Message的時(shí)候，用二分查找就可以定位到該Message在哪個(gè)段中。

2. 為數(shù)據(jù)文件建 索引數(shù)據(jù)文件分段 使得可以在一個(gè)較小的數(shù)據(jù)文件中查找對(duì)應(yīng)offset的Message 了，但是這依然需要順序掃描才能找到對(duì)應(yīng)offset的Message。
   為了進(jìn)一步提高查找的效率，Kafka為每個(gè)分段后的數(shù)據(jù)文件建立了索引文件，文件名與數(shù)據(jù)文件的名字是一樣的，只是文件擴(kuò)展名為.index。

4. Kafka數(shù)據(jù)怎么保障不丟失？

分三個(gè)點(diǎn)說，一個(gè)是生產(chǎn)者端，一個(gè)消費(fèi)者端，一個(gè)broker端。

1. 生產(chǎn)者數(shù)據(jù)的不丟失

kafka的ack機(jī)制：在kafka發(fā)送數(shù)據(jù)的時(shí)候，每次發(fā)送消息都會(huì)有一個(gè)確認(rèn)反饋機(jī)制，確保消息正常的能夠被收到，其中狀態(tài)有0，1，-1。

如果是同步模式：
ack設(shè)置為0，風(fēng)險(xiǎn)很大，一般不建議設(shè)置為0。即使設(shè)置為1，也會(huì)隨著leader宕機(jī)丟失數(shù)據(jù)。所以如果要嚴(yán)格保證生產(chǎn)端數(shù)據(jù)不丟失，可設(shè)置為-1。

如果是異步模式：
也會(huì)考慮ack的狀態(tài)，除此之外，異步模式下的有個(gè)buffer，通過buffer來進(jìn)行控制數(shù)據(jù)的發(fā)送，有兩個(gè)值來進(jìn)行控制，時(shí)間閾值與消息的數(shù)量閾值，如果buffer滿了數(shù)據(jù)還沒有發(fā)送出去，有個(gè)選項(xiàng)是配置是否立即清空buffer?？梢栽O(shè)置為-1，永久阻塞，也就數(shù)據(jù)不再生產(chǎn)。異步模式下，即使設(shè)置為-1。也可能因?yàn)槌绦騿T的不科學(xué)操作，操作數(shù)據(jù)丟失，比如kill -9，但這是特別的例外情況。

注：
ack=0：producer不等待broker同步完成的確認(rèn)，繼續(xù)發(fā)送下一條(批)信息。
ack=1（默認(rèn)）：producer要等待leader成功收到數(shù)據(jù)并得到確認(rèn)，才發(fā)送下一條message。
ack=-1：producer得到follwer確認(rèn)，才發(fā)送下一條數(shù)據(jù)。

1. 消費(fèi)者數(shù)據(jù)的不丟失

通過offset commit 來保證數(shù)據(jù)的不丟失，kafka自己記錄了每次消費(fèi)的offset數(shù)值，下次繼續(xù)消費(fèi)的時(shí)候，會(huì)接著上次的offset進(jìn)行消費(fèi)。

而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消費(fèi)者在運(yùn)行過程中掛掉了，再次啟動(dòng)的時(shí)候會(huì)找到offset的值，找到之前消費(fèi)消息的位置，接著消費(fèi)，由于 offset 的信息寫入的時(shí)候并不是每條消息消費(fèi)完成后都寫入的，所以這種情況有可能會(huì)造成重復(fù)消費(fèi)，但是不會(huì)丟失消息。

唯一例外的情況是，我們?cè)诔绦蛑薪o原本做不同功能的兩個(gè)consumer組設(shè)置
KafkaSpoutConfig.bulider.setGroupid的時(shí)候設(shè)置成了一樣的groupid，這種情況會(huì)導(dǎo)致這兩個(gè)組共享同一份數(shù)據(jù)，就會(huì)產(chǎn)生組A消費(fèi)partition1，partition2中的消息，組B消費(fèi)partition3的消息，這樣每個(gè)組消費(fèi)的消息都會(huì)丟失，都是不完整的。 為了保證每個(gè)組都獨(dú)享一份消息數(shù)據(jù)，groupid一定不要重復(fù)才行。

1. kafka集群中的broker的數(shù)據(jù)不丟失

每個(gè)broker中的partition我們一般都會(huì)設(shè)置有replication（副本）的個(gè)數(shù)，生產(chǎn)者寫入的時(shí)候首先根據(jù)分發(fā)策略（有partition按partition，有key按key，都沒有輪詢）寫入到leader中，follower（副本）再跟leader同步數(shù)據(jù)，這樣有了備份，也可以保證消息數(shù)據(jù)的不丟失。

5. 采集數(shù)據(jù)為什么選擇kafka？

采集層 主要可以使用Flume, Kafka等技術(shù)。

Flume：Flume 是管道流方式，提供了很多的默認(rèn)實(shí)現(xiàn)，讓用戶通過參數(shù)部署，及擴(kuò)展API.

Kafka：Kafka是一個(gè)可持久化的分布式的消息隊(duì)列。 Kafka 是一個(gè)非常通用的系統(tǒng)。你可以有許多生產(chǎn)者和很多的消費(fèi)者共享多個(gè)主題Topics。

相比之下,Flume是一個(gè)專用工具被設(shè)計(jì)為旨在往HDFS，HBase發(fā)送數(shù)據(jù)。它對(duì)HDFS有特殊的優(yōu)化，并且集成了Hadoop的安全特性。

所以，Cloudera 建議如果數(shù)據(jù)被多個(gè)系統(tǒng)消費(fèi)的話，使用kafka；如果數(shù)據(jù)被設(shè)計(jì)給Hadoop使用，使用Flume。

6. kafka 重啟是否會(huì)導(dǎo)致數(shù)據(jù)丟失？

1. kafka是將數(shù)據(jù)寫到磁盤的，一般數(shù)據(jù)不會(huì)丟失。

2. 但是在重啟kafka過程中，如果有消費(fèi)者消費(fèi)消息，那么kafka如果來不及提交offset，可能會(huì)造成數(shù)據(jù)的不準(zhǔn)確（丟失或者重復(fù)消費(fèi)）。

7. kafka 宕機(jī)了如何解決？

1. 先考慮業(yè)務(wù)是否受到影響

kafka 宕機(jī)了，首先我們考慮的問題應(yīng)該是所提供的服務(wù)是否因?yàn)殄礄C(jī)的機(jī)器而受到影響，如果服務(wù)提供沒問題，如果實(shí)現(xiàn)做好了集群的容災(zāi)機(jī)制，那么這塊就不用擔(dān)心了。

1. 節(jié)點(diǎn)排錯(cuò)與恢復(fù)

想要恢復(fù)集群的節(jié)點(diǎn)，主要的步驟就是通過日志分析來查看節(jié)點(diǎn)宕機(jī)的原因，從而解決，重新恢復(fù)節(jié)點(diǎn)。

8. 為什么Kafka不支持讀寫分離？

在 Kafka 中，生產(chǎn)者寫入消息、消費(fèi)者讀取消息的操作都是與 leader 副本進(jìn)行交互的，從 而實(shí)現(xiàn)的是一種主寫主讀的生產(chǎn)消費(fèi)模型。
Kafka 并不支持主寫從讀，因?yàn)橹鲗憦淖x有 2 個(gè)很明顯的缺點(diǎn):

1. 數(shù)據(jù)一致性問題：數(shù)據(jù)從主節(jié)點(diǎn)轉(zhuǎn)到從節(jié)點(diǎn)必然會(huì)有一個(gè)延時(shí)的時(shí)間窗口，這個(gè)時(shí)間 窗口會(huì)導(dǎo)致主從節(jié)點(diǎn)之間的數(shù)據(jù)不一致。某一時(shí)刻，在主節(jié)點(diǎn)和從節(jié)點(diǎn)中 A 數(shù)據(jù)的值都為 X， 之后將主節(jié)點(diǎn)中 A 的值修改為 Y，那么在這個(gè)變更通知到從節(jié)點(diǎn)之前，應(yīng)用讀取從節(jié)點(diǎn)中的 A 數(shù)據(jù)的值并不為最新的 Y，由此便產(chǎn)生了數(shù)據(jù)不一致的問題。

2. 延時(shí)問題：類似 Redis 這種組件，數(shù)據(jù)從寫入主節(jié)點(diǎn)到同步至從節(jié)點(diǎn)中的過程需要經(jīng)歷 網(wǎng)絡(luò)→主節(jié)點(diǎn)內(nèi)存→網(wǎng)絡(luò)→從節(jié)點(diǎn)內(nèi)存 這幾個(gè)階段，整個(gè)過程會(huì)耗費(fèi)一定的時(shí)間。而在 Kafka 中，主從同步會(huì)比 Redis 更加耗時(shí)，它需要經(jīng)歷 網(wǎng)絡(luò)→主節(jié)點(diǎn)內(nèi)存→主節(jié)點(diǎn)磁盤→網(wǎng)絡(luò)→從節(jié) 點(diǎn)內(nèi)存→從節(jié)點(diǎn)磁盤 這幾個(gè)階段。對(duì)延時(shí)敏感的應(yīng)用而言，主寫從讀的功能并不太適用。

而kafka的主寫主讀的優(yōu)點(diǎn)就很多了：

1. 可以簡(jiǎn)化代碼的實(shí)現(xiàn)邏輯，減少出錯(cuò)的可能;

2. 將負(fù)載粒度細(xì)化均攤，與主寫從讀相比，不僅負(fù)載效能更好，而且對(duì)用戶可控;

3. 沒有延時(shí)的影響;

4. 在副本穩(wěn)定的情況下，不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

到此，相信大家對(duì)“Kafka相關(guān)面試題有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

文章標(biāo)題：Kafka相關(guān)面試題有哪些
網(wǎng)頁(yè)URL：http://muchs.cn/article26/iiohcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、服務(wù)器托管、網(wǎng)站收錄、商城網(wǎng)站、網(wǎng)站策劃、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)