來源 過往記憶大數(shù)據(jù)

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)頁、搜索、點(diǎn)擊等活動(dòng)，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析，或者裝載到hadoop、數(shù)據(jù)倉庫中做離線分析和挖掘。

• 運(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)如下

image

詳細(xì)如下

image

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ù)。

image

假設(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)系？

image

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ì)是把所有的消息都寫入速度低容量大的硬盤，以此來換取更強(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.lxweimin.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 呢？

image

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