最近很多粉絲后臺(tái)留言問了一些大數(shù)據(jù)的面試題柜蜈，其中包括了大量的 Kafka仗谆、Spark等相關(guān)的問題，所以我特意抽出時(shí)間整理了一些大數(shù)據(jù)相關(guān)面試題淑履，本文是 Kafka 面試相關(guān)問題隶垮，其他系列面試題后面會(huì)陸續(xù)整理，歡迎關(guān)注過往記憶大數(shù)據(jù)公眾號(hào)秘噪。

1狸吞、Kafka 都有哪些特點(diǎn)？

高吞吐量指煎、低延遲：kafka每秒可以處理幾十萬條消息蹋偏，它的延遲最低只有幾毫秒，每個(gè)topic可以分多個(gè)partition, consumer group 對(duì)partition進(jìn)行consume操作贯要。

可擴(kuò)展性：kafka集群支持熱擴(kuò)展

持久性暖侨、可靠性：消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失

容錯(cuò)性：允許集群中節(jié)點(diǎn)失敵缟（若副本數(shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失敗）

高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫

2、請(qǐng)簡(jiǎn)述下你在哪些場(chǎng)景下會(huì)選擇 Kafka宅广？

日志收集：一個(gè)公司可以用Kafka可以收集各種服務(wù)的log葫掉，通過kafka以統(tǒng)一接口服務(wù)的方式開放給各種consumer，例如hadoop跟狱、HBase俭厚、Solr等。

消息系統(tǒng)：解耦和生產(chǎn)者和消費(fèi)者驶臊、緩存消息等挪挤。

用戶活動(dòng)跟蹤：Kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動(dòng)，如瀏覽網(wǎng)頁(yè)关翎、搜索扛门、點(diǎn)擊等活動(dòng)，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中纵寝，然后訂閱者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析论寨，或者裝載到hadoop、數(shù)據(jù)倉(cāng)庫(kù)中做離線分析和挖掘爽茴。

運(yùn)營(yíng)指標(biāo)：Kafka也經(jīng)常用來記錄運(yùn)營(yíng)監(jiān)控?cái)?shù)據(jù)葬凳。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋室奏，比如報(bào)警和報(bào)告火焰。

流式處理：比如spark streaming和 Flink

3、 Kafka 的設(shè)計(jì)架構(gòu)你知道嗎胧沫？

簡(jiǎn)單架構(gòu)如下

詳細(xì)如下

Kafka 架構(gòu)分為以下幾個(gè)部分

Producer ：消息生產(chǎn)者昌简，就是向 kafka broker 發(fā)消息的客戶端。

Consumer ：消息消費(fèi)者琳袄，向 kafka broker 取消息的客戶端江场。

Topic ：可以理解為一個(gè)隊(duì)列，一個(gè) Topic 又分為一個(gè)或多個(gè)分區(qū)窖逗，

Consumer Group：這是 kafka 用來實(shí)現(xiàn)一個(gè) topic 消息的廣播（發(fā)給所有的 consumer）和單播（發(fā)給任意一個(gè) consumer）的手段址否。一個(gè) topic 可以有多個(gè) Consumer Group。

Broker ：一臺(tái) kafka 服務(wù)器就是一個(gè) broker碎紊。一個(gè)集群由多個(gè) broker 組成佑附。一個(gè) broker 可以容納多個(gè) topic。

Partition：為了實(shí)現(xiàn)擴(kuò)展性仗考，一個(gè)非常大的 topic 可以分布到多個(gè) broker上音同，每個(gè) partition 是一個(gè)有序的隊(duì)列。partition 中的每條消息都會(huì)被分配一個(gè)有序的id（offset）秃嗜。將消息發(fā)給 consumer权均，kafka 只保證按一個(gè) partition 中的消息的順序顿膨，不保證一個(gè) topic 的整體（多個(gè) partition 間）的順序。

Offset：kafka 的存儲(chǔ)文件都是按照 offset.kafka 來命名叽赊，用 offset 做名字的好處是方便查找恋沃。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可必指。當(dāng)然 the first offset 就是 00000000000.kafka囊咏。

4、Kafka 分區(qū)的目的塔橡？

分區(qū)對(duì)于 Kafka 集群的好處是：實(shí)現(xiàn)負(fù)載均衡梅割。分區(qū)對(duì)于消費(fèi)者來說，可以提高并發(fā)度葛家，提高效率户辞。

5、你知道 Kafka 是如何做到消息的有序性惦银？

kafka 中的每個(gè) partition 中的消息在寫入時(shí)都是有序的咆课，而且單獨(dú)一個(gè)partition只能由一個(gè)消費(fèi)者去消費(fèi)，可以在里面保證消息的順序性扯俱。但是分區(qū)之間的消息是不保證有序的书蚪。

6、Kafka 的高可靠性是怎么實(shí)現(xiàn)的迅栅？

可以參見我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

7殊校、請(qǐng)談一談 Kafka 數(shù)據(jù)一致性原理

一致性就是說不論是老的 Leader 還是新選舉的 Leader，Consumer 都能讀到一樣的數(shù)據(jù)读存。

假設(shè)分區(qū)的副本為3为流，其中副本0是 Leader，副本1和副本2是 follower让簿，并且在 ISR 列表里面敬察。雖然副本0已經(jīng)寫入了 Message4，但是 Consumer 只能讀取到 Message2尔当。因?yàn)樗械?ISR 都同步了 Message2莲祸，只有 High Water Mark 以上的消息才支持 Consumer 讀取，而 High Water Mark 取決于 ISR 列表里面偏移量最小的分區(qū)椭迎，對(duì)應(yīng)于上圖的副本2锐帜，這個(gè)很類似于木桶原理。

這樣做的原因是還沒有被足夠多副本復(fù)制的消息被認(rèn)為是“不安全”的畜号，如果 Leader 發(fā)生崩潰缴阎，另一個(gè)副本成為新 Leader，那么這些消息很可能丟失了简软。如果我們?cè)试S消費(fèi)者讀取這些消息蛮拔，可能就會(huì)破壞一致性述暂。試想，一個(gè)消費(fèi)者從當(dāng)前 Leader（副本0） 讀取并處理了 Message4语泽，這個(gè)時(shí)候 Leader 掛掉了贸典，選舉了副本1為新的 Leader视卢，這時(shí)候另一個(gè)消費(fèi)者再去從新的 Leader 讀取消息踱卵，發(fā)現(xiàn)這個(gè)消息其實(shí)并不存在，這就導(dǎo)致了數(shù)據(jù)不一致性問題据过。

當(dāng)然惋砂，引入了 High Water Mark 機(jī)制，會(huì)導(dǎo)致 Broker 間的消息復(fù)制因?yàn)槟承┰蜃兟敲聪⒌竭_(dá)消費(fèi)者的時(shí)間也會(huì)隨之變長(zhǎng)（因?yàn)槲覀儠?huì)先等待消息復(fù)制完畢）西饵。延遲時(shí)間可以通過參數(shù) replica.lag.time.max.ms 參數(shù)配置，它指定了副本在復(fù)制消息時(shí)可被允許的最大延遲時(shí)間鳞芙。

8眷柔、ISR、OSR原朝、AR 是什么驯嘱？

ISR：In-Sync Replicas 副本同步隊(duì)列

OSR：Out-of-Sync Replicas

AR：Assigned Replicas 所有副本

ISR是由leader維護(hù)，follower從leader同步數(shù)據(jù)有一些延遲（具體可以參見?圖文了解 Kafka 的副本復(fù)制機(jī)制）喳坠，超過相應(yīng)的閾值會(huì)把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas?）列表鞠评，新加入的follower也會(huì)先存放在OSR中。AR=ISR+OSR壕鹉。

9剃幌、LEO、HW晾浴、LSO负乡、LW等分別代表什么

LEO：是 LogEndOffset 的簡(jiǎn)稱，代表當(dāng)前日志文件中下一條

HW：水位或水蛹够恕（watermark）一詞抖棘，也可稱為高水位(high watermark)，通常被用在流式處理領(lǐng)域（比如Apache Flink笙各、Apache Spark等）钉答，以表征元素或事件在基于時(shí)間層面上的進(jìn)度。在Kafka中杈抢，水位的概念反而與時(shí)間無關(guān)数尿，而是與位置信息相關(guān)。嚴(yán)格來說惶楼，它表示的就是位置信息右蹦，即位移（offset）诊杆。取 partition 對(duì)應(yīng)的 ISR中 最小的 LEO 作為 HW，consumer 最多只能消費(fèi)到 HW 所在的位置上一條信息何陆。

LSO：是?LastStableOffset?的簡(jiǎn)稱晨汹，對(duì)未完成的事務(wù)而言，LSO 的值等于事務(wù)中第一條消息的位置(firstUnstableOffset)贷盲，對(duì)已完成的事務(wù)而言淘这，它的值同 HW 相同

LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。

10巩剖、Kafka 在什么情況下會(huì)出現(xiàn)消息丟失铝穷？

可以參見我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

11、怎么盡可能保證 Kafka 的可靠性

可以參見我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

12佳魔、消費(fèi)者和消費(fèi)者組有什么關(guān)系曙聂？

每個(gè)消費(fèi)者從屬于消費(fèi)組。具體關(guān)系如下：

13鞠鲜、Kafka 的每個(gè)分區(qū)只能被一個(gè)消費(fèi)者線程宁脊，如何做到多個(gè)線程同時(shí)消費(fèi)一個(gè)分區(qū)？

參見我這篇文章：Airbnb 是如何通過 balanced Kafka reader 來擴(kuò)展 Spark streaming 實(shí)時(shí)流處理能力的

14贤姆、數(shù)據(jù)傳輸?shù)氖聞?wù)有幾種榆苞？

數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：

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

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

（3）精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被

15弄砍、Kafka 消費(fèi)者是否可以消費(fèi)指定分區(qū)消息仙畦？

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

16、Kafka消息是采用Pull模式碴卧，還是Push模式弱卡？

Kafka最初考慮的問題是，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沒有可供消費(fèi)的消息兴使，將導(dǎo)致consumer不斷在循環(huán)中輪詢，直到新消息到t達(dá)照激。為了避免這點(diǎn)发魄，Kafka有個(gè)參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)

17、Kafka 消息格式的演變清楚嗎俩垃？

Kafka 的消息格式經(jīng)過了四次大變化励幼，具體可以參見我這篇文章：Apache Kafka消息格式的演變(0.7.x~0.10.x)。

18口柳、Kafka 偏移量的演變清楚嗎苹粟？

參見我這篇文章：圖解Apache Kafka消息偏移量的演變(0.7.x~0.10.x)

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

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

通過索引信息可以快速定位message和確定response的最大大小苛秕。

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

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

20、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)生的

具體可以參見Kafka創(chuàng)建Topic時(shí)如何將分區(qū)放置到不同的Broker中苟弛。

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

在啟動(dòng) Kafka 集群之前阁将，我們需要配置好 log.dirs 參數(shù)膏秫，其值是 Kafka 數(shù)據(jù)的存放目錄，這個(gè)參數(shù)可以配置多個(gè)目錄做盅，目錄之間使用逗號(hào)分隔缤削，通常這些目錄是分布在不同的磁盤上用于提高讀寫性能。

當(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ù)最少的目錄娇妓，而不是磁盤使用量最少的目錄！也就是說活鹰，如果你給 log.dirs 參數(shù)新增了一個(gè)新的磁盤哈恰，新的分區(qū)目錄肯定是先在這個(gè)新的磁盤上創(chuàng)建直到這個(gè)新的磁盤目錄擁有的分區(qū)目錄不是最少為止。

具體可以參見我博客：https://www.iteblog.com/archives/2231.html

22志群、談一談 Kafka 的再均衡

在Kafka中着绷，當(dāng)有新消費(fèi)者加入或者訂閱的topic數(shù)發(fā)生變化時(shí)，會(huì)觸發(fā)Rebalance(再均衡：在同一個(gè)消費(fèi)者組當(dāng)中锌云，分區(qū)的所有權(quán)從一個(gè)消費(fèi)者轉(zhuǎn)移到另外一個(gè)消費(fèi)者)機(jī)制荠医，Rebalance顧名思義就是重新均衡消費(fèi)者消費(fèi)。Rebalance的過程如下：

第一步：所有成員都向coordinator發(fā)送請(qǐng)求，請(qǐng)求入組彬向。一旦所有成員都發(fā)送了請(qǐng)求兼贡，coordinator會(huì)從中選擇一個(gè)consumer擔(dān)任leader的角色，并把組成員信息以及訂閱信息發(fā)給leader娃胆。

第二步：leader開始分配消費(fèi)方案遍希，指明具體哪個(gè)consumer負(fù)責(zé)消費(fèi)哪些topic的哪些partition。一旦完成分配里烦，leader會(huì)將這個(gè)方案發(fā)給coordinator凿蒜。coordinator接收到分配方案之后會(huì)把方案發(fā)給各個(gè)consumer，這樣組內(nèi)的所有成員就都知道自己應(yīng)該消費(fèi)哪些分區(qū)了胁黑。

所以對(duì)于Rebalance來說废封，Coordinator起著至關(guān)重要的作用

23、談?wù)?Kafka 分區(qū)分配策略

參見我這篇文章Kafka分區(qū)分配策略(Partition Assignment Strategy)

24丧蘸、Kafka Producer 是如何動(dòng)態(tài)感知主題分區(qū)數(shù)變化的漂洋？

參見我這篇文章：Kafka Producer是如何動(dòng)態(tài)感知Topic分區(qū)數(shù)變化

25、 Kafka 是如何實(shí)現(xiàn)高吞吐率的触趴？

Kafka是分布式消息系統(tǒng)氮发，需要處理海量的消息，Kafka的設(shè)計(jì)是把所有的消息都寫入速度低容量大的硬盤冗懦，以此來?yè)Q取更強(qiáng)的存儲(chǔ)能力，但實(shí)際上仇祭，使用硬盤并沒有帶來過多的性能損失披蕉。kafka主要使用了以下幾個(gè)方式實(shí)現(xiàn)了超高的吞吐率：

順序讀寫；

零拷貝

文件分段

批量發(fā)送

數(shù)據(jù)壓縮乌奇。

具體參見：Kafka是如何實(shí)現(xiàn)高吞吐率的

26没讲、Kafka 監(jiān)控都有哪些？

參見我另外幾篇文章：Apache Kafka監(jiān)控之KafkaOffsetMonitor

雅虎開源的Kafka集群管理器(Kafka Manager)

Apache Kafka監(jiān)控之Kafka Web Console

還有 JMX

27礁苗、如何為Kafka集群選擇合適的Topics/Partitions數(shù)量

參見我另外幾篇文章：如何為Kafka集群選擇合適的Topics/Partitions數(shù)量

28爬凑、談?wù)勀銓?duì) Kafka 事務(wù)的了解？

參見這篇文章：http://www.jasongj.com/kafka/transaction/

29试伙、談?wù)勀銓?duì) Kafka 冪等的了解？

參見這篇文章：http://www.reibang.com/p/b1599f46229b

30、Kafka 缺點(diǎn)挪圾？

由于是批量發(fā)送芒划，數(shù)據(jù)并非真正的實(shí)時(shí)；

對(duì)于mqtt協(xié)議不支持蚤蔓；

不支持物聯(lián)網(wǎng)傳感數(shù)據(jù)直接接入卦溢；

僅支持統(tǒng)一分區(qū)內(nèi)消息有序，無法實(shí)現(xiàn)全局消息有序；

監(jiān)控不完善单寂，需要安裝插件贬芥；

依賴zookeeper進(jìn)行元數(shù)據(jù)管理；

31宣决、Kafka 新舊消費(fèi)者的區(qū)別

舊的 Kafka 消費(fèi)者 API 主要包括：SimpleConsumer（簡(jiǎn)單消費(fèi)者） 和 ZookeeperConsumerConnectir（高級(jí)消費(fèi)者）蘸劈。SimpleConsumer 名字看起來是簡(jiǎn)單消費(fèi)者，但是其實(shí)用起來很不簡(jiǎn)單疲扎，可以使用它從特定的分區(qū)和偏移量開始讀取消息昵时。高級(jí)消費(fèi)者和現(xiàn)在新的消費(fèi)者有點(diǎn)像，有消費(fèi)者群組椒丧，有分區(qū)再均衡壹甥，不過它使用 ZK 來管理消費(fèi)者群組，并不具備偏移量和再均衡的可操控性壶熏。

現(xiàn)在的消費(fèi)者同時(shí)支持以上兩種行為句柠，所以為啥還用舊消費(fèi)者 API 呢？

32棒假、Kafka 分區(qū)數(shù)可以增加或減少嗎溯职？為什么？

我們可以使用?bin/kafka-topics.sh?命令對(duì) Kafka增加 Kafka 的分區(qū)數(shù)據(jù)帽哑，但是 Kafka 不支持減少分區(qū)數(shù)谜酒。?

Kafka 分區(qū)數(shù)據(jù)不支持減少是由很多原因的，比如減少的分區(qū)其數(shù)據(jù)放到哪里去妻枕？是刪除僻族，還是保留？刪除的話屡谐，那么這些沒消費(fèi)的消息不就丟了述么。如果保留這些消息如何放到其他分區(qū)里面？追加到其他分區(qū)后面的話那么就破壞了 Kafka 單個(gè)分區(qū)的有序性愕掏。如果要保證刪除分區(qū)數(shù)據(jù)插入到其他分區(qū)保證有序性度秘，那么實(shí)現(xiàn)起來邏輯就會(huì)非常復(fù)雜。

本文參考

https://blog.csdn.net/linke1183982890/article/details/83303003

https://www.cnblogs.com/FG123/p/10095125.html

https://www.cnblogs.com/chenmingjun/p/10480793.html