一、開篇

我最近在看kafka的面試題，有我自己在網上找的題目，但是有的面試題挺好的，但是沒有答案，發現有一篇很好的博文再講面試題，但是沒有答案，所以我在這邊整理一下，博主的博文地址：https://blog.csdn.net/u013256816/article/details/88550812，大家可以去參考這篇原博文，下面是本人整理的答案，供大家參考，有什麼錯誤請指出，謝謝！

二、kafka面試題以及答案整理

1、Kafka的用途有哪些？使用場景如何？

1、日誌收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種consumer，例如Hadoop、Hbase、Solr等
2、消息系統：解耦和生產者和消費者、緩存消息等
3、用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發佈到kafka的topic中，然後訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到Hadoop、數據倉庫中做離線分析和挖掘
4、運營指標：Kafka也經常用來記錄運營監控數據。包括收集各種分佈式應用的數據，生產各種操作的集中反饋，比如報警和報告
5、流式處理：比如spark streaming和storm
6、事件源

2、 Kafka中的ISR、AR又代表什麼？ISR的伸縮又指什麼

1、分區中的所有副本統稱爲AR（Assigned Repllicas）。所有與leader副本保持一定程度同步的副本（包括Leader）組成ISR（In-Sync Replicas），ISR集合是AR集合中的一個子集。與leader副本同步滯後過多的副本（不包括leader）副本，組成OSR(Out-Sync Relipcas),由此可見：AR=ISR+OSR。
2、ISR集合的副本必須滿足：
副本所在節點必須維持着與zookeeper的連接；
副本最後一條消息的offset與leader副本最後一條消息的offset之間的差值不能超出指定的閾值
3、每個分區的leader副本都會維護此分區的ISR集合，寫請求首先由leader副本處理，之後follower副本會從leader副本上拉取寫入的消息，這個過程會有一定的延遲，導致follower副本中保存的消息略少於leader副本，只要未超出閾值都是可以容忍的
4、ISR的伸縮指的是Kafka在啓動的時候會開啓兩個與ISR相關的定時任務，名稱分別爲“isr-expiration"和”isr-change-propagation".。isr-expiration任務會週期性的檢測每個分區是否需要縮減其ISR集合。

3、Kafka中的HW、LEO、LSO、LW等分別代表什麼？

1、HW是High Watermak的縮寫，俗稱高水位，它表示了一個特定消息的偏移量（offset），消費之只能拉取到這個offset之前的消息。
2、LEO是Log End Offset的縮寫，它表示了當前日誌文件中下一條待寫入消息的offset。
3、LSO特指LastStableOffset。它具體與kafka的事物有關。消費端參數——isolation.level,這個參數用來配置消費者事務的隔離級別。字符串類型，“read_uncommitted”和“read_committed”。
4、 LW是Low Watermark的縮寫，俗稱“低水位”，代表AR集合中最小的logStartOffset值，副本的拉取請求（FetchRequest）和刪除請求（DeleteRecordRequest）都可能促使LW的增長。

4、Kafka中是怎麼體現消息順序性的？具體的可參考這篇博文，https://www.cnblogs.com/windpoplar/p/10747696.html

1、一個 topic，一個 partition，一個 consumer，內部單線程消費，單線程吞吐量太低，一般不會用這個。
2、寫 N 個內存 queue，具有相同 key 的數據都到同一個內存 queue；然後對於 N 個線程，每個線程分別消費一個內存 queue 即可，這樣就能保證順序性。

5、Kafka中的分區器、序列化器、攔截器是否瞭解？它們之間的處理順序是什麼？

攔截器 -> 序列化器 -> 分區器

補充：Producer攔截器(interceptor)是在Kafka 0.10版本被引入的，主要用於實現clients端的定製化控制邏輯。producer允許用戶指定多個interceptor按序作用於同一條消息從而形成一個攔截鏈(interceptor chain)。Intercetpor的實現接口是org.apache.kafka.clients.producer.ProducerInterceptor。實現下面四個方法

1）、configure(configs)：獲取配置信息和初始化數據時調用

2）、onSend(ProducerRecord)：用戶可以在該方法中對消息做任何操作，但最好保證不要修改消息所屬的topic和分區，否則會影響目標分區的計算

3）、onAcknowledgement(RecordMetadata, Exception)：該方法會在消息被應答或消息發送失敗時調用

4）、close：關閉interceptor，主要用於執行一些資源清理工作

6、Kafka生產者客戶端的整體結構是什麼樣子的？關於這一部分可以參考：https://zhuanlan.zhihu.com/p/94412266

7、消費組中的消費者個數如果超過topic的分區，那麼就會有消費者消費不到數據”這句話是否正確？如果不正確，那麼有沒有什麼hack的手段？

不正確，通過自定義分區分配策略，可以將一個consumer指定消費所有partition。

8、消費者提交消費位移時提交的是當前消費到的最新消息的offset還是offset+1?

offset+1

9、有哪些情形會造成重複消費？

消費者消費後沒有commit offset(程序崩潰/強行kill/消費耗時/自動提交偏移情況下unscrible)

10、那些情景下會造成消息漏消費？

先提交offset，後消費，有可能造成數據的重複

11、KafkaConsumer是非線程安全的，那麼怎麼樣實現多線程消費？參考：https://blog.csdn.net/clypm/article/details/80618036

1 、每個線程維護一個KafkaConsumer
2 、維護一個或多個KafkaConsumer，同時維護多個事件處理線程(worker thread)

12、簡述消費者與消費組之間的關係

消費者從屬與消費組，消費偏移以消費組爲單位。每個消費組可以獨立消費主題的所有數據，同一消費組內消費者共同消費主題數據，每個分區只能被同一消費組內一個消費者消費。

13、當你使用kafka-topics.sh創建（刪除）了一個topic之後，Kafka背後會執行什麼邏輯？

1）會在zookeeper中的/brokers/topics節點下創建一個新的topic節點，如：/brokers/topics/first
2）觸發Controller的監聽程序
3）kafka Controller 負責topic的創建工作，並更新metadata cache

14、topic的分區數可不可以增加？如果可以怎麼增加？如果不可以，那又是爲什麼？

可以增加

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3

15、topic的分區數可不可以減少？如果可以怎麼減少？如果不可以，那又是爲什麼？

不可以減少，被刪除的分區數據難以處理。

16、創建topic時如何選擇合適的分區數？https://blog.csdn.net/weixin_42641909/article/details/89294698

1）創建一個只有1個分區的topic

2）測試這個topic的producer吞吐量和consumer吞吐量。

3）假設他們的值分別是Tp和Tc，單位可以是MB/s。

4）然後假設總的目標吞吐量是Tt，那麼分區數=Tt / max（Tp，Tc）

例如：producer吞吐量=5m/s；consumer吞吐量=50m/s，期望吞吐量100m/s；

分區數=100 / 50 =2分區

分區數一般設置爲：3-10個

17、Kafka目前有那些內部topic，它們都有什麼特徵？各自的作用又是什麼？

consumer_offsets 以下劃線開頭，保存消費組的偏移

18、優先副本是什麼？它有什麼特殊的作用？

優先副本會是默認的leader副本發生leader變化時重選舉會優先選擇優先副本作爲leader

19、Kafka有哪幾處地方有分區分配的概念？簡述大致的過程及原理。參考：https://blog.csdn.net/weixin_42641909/article/details/89294698

Kafka提供的兩種分配策略： range和roundrobin，由參數partition.assignment.strategy指定，默認是range策略。

當以下事件發生時，Kafka 將會進行一次分區分配：

同一個 Consumer Group 內新增消費者

消費者離開當前所屬的Consumer Group，包括shuts down 或 crashes

訂閱的主題新增分區

1）Range strategy

Range策略是對每個主題而言的，首先對同一個主題裏面的分區按照序號進行排序，並對消費者按照字母順序進行排序。

2） RoundRobin strategy

使用RoundRobin策略有兩個前提條件必須滿足：

同一個Consumer Group裏面的所有消費者的num.streams必須相等；

每個消費者訂閱的主題必須相同。

所以這裏假設前面提到的2個消費者的num.streams = 2。

RoundRobin策略的工作原理：將所有主題的分區組成 TopicAndPartition 列表，然後對 TopicAndPartition 列表按照 hashCode 進行排序

20、簡述Kafka的日誌目錄結構。Kafka中有那些索引文件？參考：https://zhuanlan.zhihu.com/p/94412266

每個分區對應一個文件夾，文件夾的命名爲topic-0，topic-1，內部爲.log和.index文件

以及 .timeindex leader-epoch-checkpoint

21、如果我指定了一個offset，Kafka怎麼查找到對應的消息？參考:https://blog.csdn.net/moakun/article/details/101855315

1.通過文件名前綴數字x找到該絕對offset 對應消息所在文件
2.offset-x爲在文件中的相對偏移
3.通過index文件中記錄的索引找到最近的消息的位置
4.從最近位置開始逐條尋找

22、如果我指定了一個timestamp，Kafka怎麼查找到對應的消息？

參考:https://blog.csdn.net/moakun/article/details/101855315

原理同上但是時間的因爲消息體中不帶有時間戳所以不精確

23、kafka過期數據清理

日誌清理保存的策略只有delete和compact兩種

log.cleanup.policy=delete啓用刪除策略

log.cleanup.policy=compact啓用壓縮策略

24、Kafka中的冪等是怎麼實現的

Producer的冪等性指的是當發送同一條消息時，數據在Server端只會被持久化一次，數據不丟不重，但是這裏的冪等性是有條件的：

1）只能保證Producer在單個會話內不丟不重，如果Producer出現意外掛掉再重啓是無法保證的（冪等性情況下，是無法獲取之前的狀態信息，因此是無法做到跨會話級別的不丟不重）。

2）冪等性不能跨多個Topic-Partition，只能保證單個Partition內的冪等性，當涉及多個 Topic-Partition時，這中間的狀態並沒有同步。

25、kafka事務。分享一篇大佬講kafka事務的博客，這一篇講的更深入：http://matt33.com/2018/11/04/kafka-transaction/

同時分享一下這兩篇博文，感覺這篇博文講的更容易理解一些，面試我感覺看這兩篇就夠了：https://www.jianshu.com/p/64c93065473e，https://www.cnblogs.com/middleware/p/9477133.html

Kafka從0.11版本開始引入了事務支持。事務可以保證Kafka在Exactly Once語義的基礎上，生產和消費可以跨分區和會話，要麼全部成功，要麼全部失敗。

1）Producer事務

爲了實現跨分區跨會話的事務，需要引入一個全局唯一的Transaction ID，並將Producer獲得的PID和Transaction ID綁定。這樣當Producer重啓後就可以通過正在進行的Transaction ID獲得原來的PID。

爲了管理Transaction，Kafka引入了一個新的組件Transaction Coordinator。Producer就是通過和Transaction Coordinator交互獲得Transaction ID對應的任務狀態。Transaction Coordinator還負責將事務所有寫入Kafka的一個內部Topic，這樣即使整個服務重啓，由於事務狀態得到保存，進行中的事務狀態可以得到恢復，從而繼續進行。

2）Consumer事務

上述事務機制主要是從Producer方面考慮，對於Consumer而言，事務的保證就會相對較弱，尤其時無法保證Commit的信息被精確消費。這是由於Consumer可以通過offset訪問任意信息，而且不同的Segment File生命週期不同，同一事務的消息可能會出現重啓後被刪除的情況。

26、 Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？參考：https://blog.csdn.net/u013256816/article/details/89369160

控制器的選舉

Kafka Controller的選舉是依賴Zookeeper來實現的，在Kafka集羣中哪個broker能夠成功創建/controller這個臨時（EPHEMERAL）節點他就可以成爲Kafka Controller。

分區leader的選舉

https://www.jianshu.com/p/1f02328a4f2e

消費者相關的選舉

組協調器GroupCoordinator需要爲消費組內的消費者選舉出一個消費組的leader，這個選舉的算法也很簡單，分兩種情況分析。如果消費組內還沒有leader，那麼第一個加入消費組的消費者即爲消費組的leader。如果某一時刻leader消費者由於某些原因退出了消費組，那麼會重新選舉一個新的leader。

27、Kafka中的延遲隊列怎麼實現？參考：https://blog.csdn.net/u013256816/article/details/80697456

Kafka中存在大量的延遲操作，比如延遲生產、延遲拉取以及延遲刪除等。Kafka並沒有使用JDK自帶的Timer或者DelayQueue來實現延遲的功能，而是基於時間輪自定義了一個用於實現延遲功能的定時器（SystemTimer）。JDK的Timer和DelayQueue插入和刪除操作的平均時間複雜度爲O(nlog(n))，並不能滿足Kafka的高性能要求，而基於時間輪可以將插入和刪除操作的時間複雜度都降爲O(1)。Kafka中的時間輪（TimingWheel）是一個存儲定時任務的環形隊列，底層採用數組實現，數組中的每個元素可以存放一個定時任務列表（TimerTaskList）。TimerTaskList是一個環形的雙向鏈表，鏈表中的每一項表示的都是定時任務項（TimerTaskEntry），其中封裝了真正的定時任務TimerTask。時間輪由多個時間格組成，每個時間格代表當前時間輪的基本時間跨度（tickMs）。時間輪的時間格個數是固定的，可用wheelSize來表示，那麼整個時間輪的總體時間跨度（interval）可以通過公式 tickMs × wheelSize計算得出。

Kafka最全面試題整理