1.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 通過網(wǎng)絡(luò)將消息發(fā)送到 Kafka 集群，集群向消費(fèi)者提供消息

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

數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：
（1）最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸
（2）最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
（3）精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而 且僅僅被傳輸一次，這是大家所期望的

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

（1）節(jié)點(diǎn)必須可以維護(hù)和 ZooKeeper 的連接，Zookeeper 通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連 接
（2）如果節(jié)點(diǎn)是個(gè) follower,他必須能及時(shí)的同步 leader 的寫操作，延時(shí)不能太久

4.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ā)送到目的地了

5、Kafa consumer 是否可以消費(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)之前的消息，這是很有意義的

6、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ā)

7.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

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

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

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

(1).Kafka 持久化日志，這些日志可以被重復(fù)讀取和無限期保留 (2).Kafka 是一個(gè)分布式系統(tǒng)：它以集群的方式運(yùn)行，可以靈活伸縮，在內(nèi)部通過復(fù)制數(shù)據(jù) 提升容錯(cuò)能力和高可用性 (3).Kafka 支持實(shí)時(shí)的流式處理

10.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)生的

11.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ū)目錄不是最少為止。

12.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 最后一條消息的偏移 量命名

13.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ì)丟失

14.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)

15.消費(fèi)者負(fù)載均衡策略

一個(gè)消費(fèi)者組中的一個(gè)分片對(duì)應(yīng)一個(gè)消費(fèi)者成員，他能保證每個(gè)消費(fèi)者成員都能訪問，如 果組中成員太多會(huì)有空閑的成員

16.數(shù)據(jù)有序

一個(gè)消費(fèi)者組里它的內(nèi)部是有序的 消費(fèi)者組與消費(fèi)者組之間是無序的

17.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

18.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 通過網(wǎng)絡(luò)將消息發(fā)送到 Kafka 集群，集群向消費(fèi)者提供消息

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

數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：
（1）最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸
（2）最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
（3）精確的一次（Exactly once）:不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅
僅被傳輸一次，這是大家所期望的

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

（1）節(jié)點(diǎn)必須可以維護(hù)和 ZooKeeper 的連接，Zookeeper 通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連
接
（2）如果節(jié)點(diǎn)是個(gè) follower,他必須能及時(shí)的同步 leader 的寫操作，延時(shí)不能太久

21.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ā)送到目的地了

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

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

23、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 和 ApacheFlume 采用了 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ā)

24.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

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

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

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

(1).Kafka 持久化日志，這些日志可以被重復(fù)讀取和無限期保留
(2).Kafka 是一個(gè)分布式系統(tǒng)：它以集群的方式運(yùn)行，可以靈活伸縮，在內(nèi)部通過復(fù)制數(shù)據(jù)提升容錯(cuò)能力和高可用性
(3).Kafka 支持實(shí)時(shí)的流式處理

27.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)生的

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

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

總結(jié)

以上是生活随笔為你收集整理的Kafka面试专题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。