Kafka相關面試題詳解

文章目錄

2.Kafka如何實現每秒上百萬的超高併發寫入？

面試題列表

Kafka的用途有哪些？使用場景如何？
Kafka中的ISR、AR又代表什麼？ISR的伸縮又指什麼
Kafka中的HW、LEO、LSO、LW等分別代表什麼？
Kafka中是怎麼體現消息順序性的？
Kafka中的分區器、序列化器、攔截器是否瞭解？它們之間的處理順序是什麼？
Kafka生產者客戶端的整體結構是什麼樣子的？
Kafka生產者客戶端中使用了幾個線程來處理？分別是什麼？
Kafka的舊版Scala的消費者客戶端的設計有什麼缺陷？
“消費組中的消費者個數如果超過topic的分區，那麼就會有消費者消費不到數據”這句話是否正確？如果正確，那麼有沒有什麼hack的手段？
消費者提交消費位移時提交的是當前消費到的最新消息的offset還是offset+1?
有哪些情形會造成重複消費？
那些情景下會造成消息漏消費？
KafkaConsumer是非線程安全的，那麼怎麼樣實現多線程消費？
簡述消費者與消費組之間的關係
當你使用kafka-topics.sh創建（刪除）了一個topic之後，Kafka背後會執行什麼邏輯？
topic的分區數可不可以增加？如果可以怎麼增加？如果不可以，那又是爲什麼？
topic的分區數可不可以減少？如果可以怎麼減少？如果不可以，那又是爲什麼？
創建topic時如何選擇合適的分區數？
Kafka目前有那些內部topic，它們都有什麼特徵？各自的作用又是什麼？
優先副本是什麼？它有什麼特殊的作用？
Kafka有哪幾處地方有分區分配的概念？簡述大致的過程及原理
簡述Kafka的日誌目錄結構
Kafka中有那些索引文件？
如果我指定了一個offset，Kafka怎麼查找到對應的消息？
如果我指定了一個timestamp，Kafka怎麼查找到對應的消息？
聊一聊你對Kafka的Log Retention的理解
聊一聊你對Kafka的Log Compaction的理解
聊一聊你對Kafka底層存儲的理解（頁緩存、內核層、塊層、設備層）
聊一聊Kafka的延時操作的原理
聊一聊Kafka控制器的作用
消費再均衡的原理是什麼？（提示：消費者協調器和消費組協調器）
Kafka中的冪等是怎麼實現的
Kafka中的事務是怎麼實現的（這題我去面試6加被問4次，照着答案念也要念十幾分鍾，面試官簡直湊不要臉）
Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？
失效副本是指什麼？有那些應對措施？
多副本下，各個副本中的HW和LEO的演變過程
爲什麼Kafka不支持讀寫分離？
Kafka在可靠性方面做了哪些改進？（HW, LeaderEpoch）
Kafka中怎麼實現死信隊列和重試隊列？
Kafka中的延遲隊列怎麼實現（這題被問的比事務那題還要多！！！聽說你會Kafka，那你說說延遲隊列怎麼實現？）
Kafka中怎麼做消息審計？
Kafka中怎麼做消息軌跡？
Kafka中有那些配置參數比較有意思？聊一聊你的看法
Kafka中有那些命名比較有意思？聊一聊你的看法
Kafka有哪些指標需要着重關注？
怎麼計算Lag？(注意read_uncommitted和read_committed狀態下的不同)
Kafka的那些設計讓它有如此高的性能？
Kafka有什麼優缺點？
還用過什麼同質類的其它產品，與Kafka相比有什麼優缺點？
爲什麼選擇Kafka?
在使用Kafka的過程中遇到過什麼困難？怎麼解決的？
怎麼樣才能確保Kafka極大程度上的可靠性？
聊一聊你對Kafka生態的理解

1.突發宕機，Kafka寫入的數據如何保證不丟失？

原文地址：http://developer.51cto.com/art/201903/593232.htm

這篇給大家聊下寫入 Kafka 的數據該如何保證其不丟失?

我們暫且不考慮寫磁盤的具體過程，先大致看看下面的圖，這代表了 Kafka 的核心架構原理。

Kafka 分佈式存儲架構

那麼現在問題來了，如果每天產生幾十 TB 的數據，難道都寫一臺機器的磁盤上嗎?這明顯是不靠譜的啊!

所以說，這裏就得考慮數據的分佈式存儲了，我們結合 Kafka 的具體情況來說說。

在 Kafka 裏面，有一個核心的概念叫做“Topic”，這個 Topic 你就姑且認爲是一個數據集合吧。

舉個例子，如果你現在有一份網站的用戶行爲數據要寫入 Kafka，你可以搞一個 Topic 叫做“user_access_log_topic”，這裏寫入的都是用戶行爲數據。

然後如果你要把電商網站的訂單數據的增刪改變更記錄寫 Kafka，那可以搞一個 Topic 叫做“order_tb_topic”，這裏寫入的都是訂單表的變更記錄。

然後假如說咱們舉個例子，就說這個用戶行爲 Topic 吧，裏面如果每天寫入幾十 TB 的數據，你覺得都放一臺機器上靠譜嗎?

明顯不太靠譜，所以 Kafka 有一個概念叫做 Partition，就是把一個 Topic 數據集合拆分爲多個數據分區，你可以認爲是多個數據分片，每個 Partition 可以在不同的機器上，儲存部分數據。

這樣，不就可以把一個超大的數據集合分佈式存儲在多臺機器上了嗎?大家看下圖，一起來體會一下。

Kafka 高可用架構

但是這個時候，我們又會遇到一個問題，就是萬一某臺機器宕機了，這臺機器上的那個 Partition 管理的數據不就丟失了嗎?

所以說，我們還得做多副本冗餘，每個 Partition 都可以搞一個副本放在別的機器上，這樣某臺機器宕機，只不過是 Partition 其中一個副本丟失。

如果某個 Partition 有多副本的話，Kafka 會選舉其中一個 Parititon 副本作爲 Leader，然後其他的 Partition 副本是 Follower。

只有 Leader Partition 是對外提供讀寫操作的，Follower Partition 就是從 Leader Partition 同步數據。

一旦 Leader Partition 宕機了，就會選舉其他的 Follower Partition 作爲新的 Leader Partition 對外提供讀寫服務，這不就實現了高可用架構了?

大家看下面的圖，看看這個過程：

Kafka 寫入數據丟失問題

現在我們來看看，什麼情況下 Kafka 中寫入數據會丟失呢?其實也很簡單，大家都知道寫入數據都是往某個 Partition 的 Leader 寫入的，然後那個 Partition 的 Follower 會從 Leader 同步數據。

但是萬一 1 條數據剛寫入 Leader Partition，還沒來得及同步給 Follower，此時 Leader Partiton 所在機器突然就宕機了呢?

大家看下圖：

如上圖，這個時候有一條數據是沒同步到 Partition0 的 Follower 上去的，然後 Partition0 的 Leader 所在機器宕機了。

此時就會選舉 Partition0 的 Follower 作爲新的 Leader 對外提供服務，然後用戶是不是就讀不到剛纔寫入的那條數據了?

因爲 Partition0 的 Follower 上是沒有同步到的一條數據的。這個時候就會造成數據丟失的問題。

Kafka 的 ISR 機制是什麼?

現在我們先留着這個問題不說具體怎麼解決，先回過頭來看一個 Kafka 的核心機制，就是 ISR 機制。

這個機制簡單來說，就是會自動給每個 Partition 維護一個 ISR 列表，這個列表裏一定會有 Leader，然後還會包含跟 Leader 保持同步的 Follower。

也就是說，只要 Leader 的某個 Follower 一直跟他保持數據同步，那麼就會存在於 ISR 列表裏。

但是如果 Follower 因爲自身發生一些問題，導致不能及時的從 Leader 同步數據過去，那麼這個 Follower 就會被認爲是“out-of-sync”，被從 ISR 列表裏踢出去。

所以大家先得明白這個 ISR 是什麼，說白了，就是 Kafka 自動維護和監控哪些 Follower 及時的跟上了 Leader 的數據同步。

Kafka 寫入的數據如何保證不丟失?

所以如果要讓寫入 Kafka 的數據不丟失，你需要保證如下幾點：

每個 Partition 都至少得有 1 個 Follower 在 ISR 列表裏，跟上了 Leader 的數據同步。
每次寫入數據的時候，都要求至少寫入 Partition Leader 成功，同時還有至少一個 ISR 裏的 Follower 也寫入成功，纔算這個寫入是成功了。
如果不滿足上述兩個條件，那就一直寫入失敗，讓生產系統不停的嘗試重試，直到滿足上述兩個條件，然後才能認爲寫入成功。
按照上述思路去配置相應的參數，才能保證寫入 Kafka 的數據不會丟失。

好!現在咱們來分析一下上面幾點要求。

第一條，必須要求至少一個 Follower 在 ISR 列表裏。

那必須的啊，要是 Leader 沒有 Follower 了，或者是 Follower 都沒法及時同步 Leader 數據，那麼這個事兒肯定就沒法弄下去了。

第二條，每次寫入數據的時候，要求 Leader 寫入成功以外，至少一個 ISR 裏的 Follower 也寫成功。

大家看下面的圖，這個要求就是保證說，每次寫數據，必須是 Leader 和 Follower 都寫成功了，才能算是寫成功，保證一條數據必須有兩個以上的副本。

這個時候萬一 Leader 宕機，就可以切換到那個 Follower 上去，那麼 Follower 上是有剛寫入的數據的，此時數據就不會丟失了。

如上圖所示，假如現在 Leader 沒有 Follower 了，或者是剛寫入 Leader，Leader 立馬就宕機，還沒來得及同步給 Follower。

在這種情況下，寫入就會失敗，然後你就讓生產者不停的重試，直到 Kafka 恢復正常滿足上述條件，才能繼續寫入。這樣就可以讓寫入 Kafka 的數據不丟失。

總結

總結一下，其實 Kafka 的數據丟失問題，涉及到方方面面。

譬如生產端的緩存問題，包括消費端的問題，同時 Kafka 自己內部的底層算法和機制也可能導致數據丟失。

但是平時寫入數據遇到比較大的一個問題，就是 Leader 切換時可能導致數據丟失。所以本文僅僅是針對這個問題說了一下生產環境解決這個問題的方案。

2.Kafka如何實現每秒上百萬的超高併發寫入？

http://developer.51cto.com/art/201903/592916.htm

這篇文章來聊一下 Kafka 的一些架構設計原理，這也是互聯網公司面試時非常高頻的技術考點。

Kafka 是高吞吐低延遲的高併發、高性能的消息中間件，在大數據領域有極爲廣泛的運用。配置良好的 Kafka 集羣甚至可以做到每秒幾十萬、上百萬的超高併發寫入。

那麼 Kafka 到底是如何做到這麼高的吞吐量和性能的呢?這篇文章我們來詳細說一下。

頁緩存技術 + 磁盤順序寫

首先 Kafka 每次接收到數據都會往磁盤上去寫，如下圖所示：

那麼在這裏我們不禁有一個疑問了，如果把數據基於磁盤來存儲，頻繁的往磁盤文件裏寫數據，這個性能會不會很差?大家肯定都覺得磁盤寫性能是極差的。

沒錯，要是真的跟上面那個圖那麼簡單的話，那確實這個性能是比較差的。

但是實際上 Kafka 在這裏有極爲優秀和出色的設計，就是爲了保證數據寫入性能，首先 Kafka 是基於操作系統的頁緩存來實現文件寫入的。

操作系統本身有一層緩存，叫做 Page Cache，是在內存裏的緩存，我們也可以稱之爲 OS Cache，意思就是操作系統自己管理的緩存。

你在寫入磁盤文件的時候，可以直接寫入這個 OS Cache 裏，也就是僅僅寫入內存中，接下來由操作系統自己決定什麼時候把 OS Cache 裏的數據真的刷入磁盤文件中。

僅僅這一個步驟，就可以將磁盤文件寫性能提升很多了，因爲其實這裏相當於是在寫內存，不是在寫磁盤，大家看下圖：

接着另外一個就是 kafka 寫數據的時候，非常關鍵的一點，它是以磁盤順序寫的方式來寫的。

也就是說，僅僅將數據追加到文件的末尾，不是在文件的隨機位置來修改數據。

普通的機械磁盤如果你要是隨機寫的話，確實性能極差，也就是隨便找到文件的某個位置來寫數據。

但是如果你是追加文件末尾按照順序的方式來寫數據的話，那麼這種磁盤順序寫的性能基本上可以跟寫內存的性能本身也是差不多的。

所以大家就知道了，上面那個圖裏，Kafka 在寫數據的時候，一方面基於 OS 層面的 Page Cache 來寫數據，所以性能很高，本質就是在寫內存罷了。

另外一個，它是採用磁盤順序寫的方式，所以即使數據刷入磁盤的時候，性能也是極高的，也跟寫內存是差不多的。

基於上面兩點，Kafka 就實現了寫入數據的超高性能。那麼大家想想，假如說 Kafka 寫入一條數據要耗費 1 毫秒的時間，那麼是不是每秒就是可以寫入 1000 條數據?

但是假如 Kafka 的性能極高，寫入一條數據僅僅耗費 0.01 毫秒呢?那麼每秒是不是就可以寫入 10 萬條數據?

所以要保證每秒寫入幾萬甚至幾十萬條數據的核心點，就是儘可能提升每條數據寫入的性能，這樣就可以在單位時間內寫入更多的數據量，提升吞吐量。

零拷貝技術

說完了寫入這塊，再來談談消費這塊。

大家應該都知道，從 Kafka 裏我們經常要消費數據，那麼消費的時候實際上就是要從 Kafka 的磁盤文件裏讀取某條數據然後發送給下游的消費者，如下圖所示：

那麼這裏如果頻繁的從磁盤讀數據然後發給消費者，性能瓶頸在哪裏呢?

假設要是 Kafka 什麼優化都不做，就是很簡單的從磁盤讀數據發送給下游的消費者，那麼大概過程如下所示：

先看看要讀的數據在不在 OS Cache 裏，如果不在的話就從磁盤文件裏讀取數據後放入 OS Cache。
接着從操作系統的 OS Cache 裏拷貝數據到應用程序進程的緩存裏，再從應用程序進程的緩存裏拷貝數據到操作系統層面的 Socket 緩存裏。
***從 Socket 緩存裏提取數據後發送到網卡，***發送出去給下游消費。

整個過程，如下圖所示：

大家看上圖，很明顯可以看到有兩次沒必要的拷貝吧!一次是從操作系統的 Cache 裏拷貝到應用進程的緩存裏，接着又從應用程序緩存裏拷貝回操作系統的 Socket 緩存裏。

而且爲了進行這兩次拷貝，中間還發生了好幾次上下文切換，一會兒是應用程序在執行，一會兒上下文切換到操作系統來執行。

所以這種方式來讀取數據是比較消耗性能的。Kafka 爲了解決這個問題，在讀數據的時候是引入零拷貝技術。

也就是說，直接讓操作系統的 Cache 中的數據發送到網卡後傳輸給下游的消費者，中間跳過了兩次拷貝數據的步驟，Socket 緩存中僅僅會拷貝一個描述符過去，不會拷貝數據到 Socket 緩存。

大家看下圖，體會一下這個精妙的過程：

通過零拷貝技術，就不需要把 OS Cache 裏的數據拷貝到應用緩存，再從應用緩存拷貝到 Socket 緩存了，兩次拷貝都省略了，所以叫做零拷貝。

對 Socket 緩存僅僅就是拷貝數據的描述符過去，然後數據就直接從 OS Cache 中發送到網卡上去了，這個過程大大的提升了數據消費時讀取文件數據的性能。

而且大家會注意到，在從磁盤讀數據的時候，會先看看 OS Cache 內存中是否有，如果有的話，其實讀數據都是直接讀內存的。

如果 Kafka 集羣經過良好的調優，大家會發現大量的數據都是直接寫入 OS Cache 中，然後讀數據的時候也是從 OS Cache 中讀。

相當於是 Kafka 完全基於內存提供數據的寫和讀了，所以這個整體性能會極其的高。

總結

通過這篇文章對 Kafka 底層的頁緩存技術的使用，磁盤順序寫的思路，以及零拷貝技術的運用，大家應該就明白 Kafka 每臺機器在底層對數據進行寫和讀的時候採取的是什麼樣的思路，爲什麼它的性能可以那麼高，做到每秒幾十萬的吞吐量。

這種設計思想對我們平時自己設計中間件的架構，或者是出去面試的時候，都有很大的幫助。

3.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)等分別代表什麼？

ISR(In-Sync Replicas )：與leader保持同步的follower集合
AR(Assigned Replicas)：分區的所有副本

ISR是由leader維護，follower從leader同步數據有一些延遲（包括延遲時間replica.lag.time.max.ms和延遲條數replica.lag.max.messages兩個維度, 當前最新的版本0.10.x中只支持replica.lag.time.max.ms這個維度），任意一個超過閾值都會把follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的follower也會先存放在OSR中。AR=ISR+OSR。

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

LEO(LogEndOffset)：標識當前日誌文件下一條待寫入的 offset
HW(High Watermark)：一個分區中所有副本最小的offset,取一個partition對應的ISR中最小的LEO作爲HW，consumer最多隻能消費到HW所在的位置上一條信息。

HW/LEO這兩個都是指最後一條的下一條的位置而不是指最後一條的位置。

LSO(Last Stable Offset): 對未完成的事務而言，LSO 的值等於事務中第一條消息的位置(firstUnstableOffset)，對已完成的事務而言，它的值同 HW 相同
LW(Low Watermark): 低水位, 代表 AR 集合中最小的 logStartOffset 值

5. Kafka的用途有哪些？使用場景如何？

總結下來就幾個字:異步處理、日常系統解耦、削峯、提速、廣播

如果再說具體一點例如:消息,網站活動追蹤,監測指標,日誌聚合,流處理,事件採集,提交日誌等

6.Kafka中是怎麼體現消息順序性的？

每個分區內，每條消息都有一個offset，故只能保證分區內有序。

kafka每個partition中的消息在寫入時都是有序的，消費時，每個partition只能被每一個group中的一個消費者消費，保證了消費時也是有序的。

整個topic不保證有序。如果爲了保證topic整個有序，那麼將partition調整爲1。

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

見Producer API小節

分區器:根據鍵值確定消息應該處於哪個分區中，默認情況下使用輪詢分區，可以自行實現分區器接口自定義分區邏輯
序列化器:鍵序列化器和值序列化器，將鍵和值都轉爲二進制流還有反序列化器將二進制流轉爲指定類型數據
攔截器:兩個方法 doSend()方法會在序列化之前完成 onAcknowledgement()方法在消息確認或失敗時調用可以添加多個攔截器按順序執行

調用順序: 攔截器doSend() -> 序列化器 -> 分區器

8.Kafka生產者客戶端的整體結構是什麼樣子的？使用了幾個線程來處理？分別是什麼？

2個線程，主線程和Sender線程。

主線程：負責創建消息，然後通過分區器、序列化器、攔截器作用之後緩存到累加器RecordAccumulator中。
Sender線程：負責將RecordAccumulator中消息發送到kafka中.

9.“消費組中的消費者個數如果超過topic的分區，那麼就會有消費者消費不到數據”這句話是否正確？

正確,因爲一個分區只能被同一個消費組中的一個消費者消費，如果消費者組中消費者個數超過分區數，那麼肯定有一個沒有辦法消費到數據

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

offset+1

11.有哪些情形會造成重複消費？（重點）

見4.2.2和3.3.3小節詳解

兩種情況可能出現重複消費

當ack=-1時，如果在follower同步完成後，broker發送ack之前，leader發生故障，導致沒有返回ack給Producer，由於失敗重試機制，又會給新選舉出來的leader發送數據，造成數據重複。
（手動管理offset時，先消費後提交offset）消費者消費後沒有commit offset(程序崩潰/強行kill/消費耗時/自動提交偏移情況下unscrible)

12.哪些情景會造成消息漏消費？（重點）

見4.2.2和3.3.3小節詳解

（手動管理offset時，先提交offset後消費）先提交offset，後消費，有可能造成數據的重複

如果先提交offset，後消費，可能會出現數據漏消費問題。比如，要消費0,1,2,我先提交offset ，此時__consumer_offsets的值爲4，但等我提交完offset之後，還沒有消費之前，消費者掛掉了，這時等消費者重新活過來後，讀取的__consumer_offsets值爲4，就會從4開始消費，導致消息0,1,2出現漏消費問題。
當ack=0時，producer不等待broker的ack，這一操作提供了一個最低的延遲，broker一接收到還沒有寫入磁盤就已經返回，當broker故障時有可能丟失數據；
當ack=1時，producer等待broker的ack，partition的leader落盤成功後返回ack，如果在follower同步成功之前leader故障，而由於已經返回了ack，系統默認新選舉的leader已經有了數據，從而不會進行失敗重試，那麼將會丟失數據

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

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

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

可以增加，可以通過以下命令增加，也可以通過Kafka Manager等圖形化管理工具進行分區的添加

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

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

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

16.Kafka有內部的topic嗎？如果有是什麼？有什麼所用？

__consumer_offsets 以雙下劃線開頭，保存消費組的偏移量

17.Kafka分區分配的概念？

見3.5.2小節

一個topic多個分區，一個消費者組多個消費者，故需要將分區分配個消費者(roundrobin、range)

在 Kafka內部存在兩種默認的分區分配策略：Range和 RoundRobin，最新還有sticky。

Range是默認策略。Range是對每個Topic而言的（即一個Topic一個Topic分），首先對同一個Topic裏面的分區按照序號進行排序，並對消費者按照字母順序進行排序。然後用Partitions分區的個數除以消費者線程的總數來決定每個消費者線程消費幾個分區。如果除不盡，那麼前面幾個消費者線程將會多消費一個分區。

例如：我們有10個分區，兩個消費者（C1，C2），3個消費者線程，10 / 3 = 3而且除不盡。

C1-0 將消費 0, 1, 2, 3 分區

C2-0 將消費 4, 5, 6 分區

C2-1 將消費 7, 8, 9 分區

RoundRobin：前提：同一個Consumer Group裏面的所有消費者的num.streams（消費者消費線程數）必須相等；每個消費者訂閱的主題必須相同。

第一步：將所有主題分區組成TopicAndPartition列表，然後對TopicAndPartition列表按照hashCode進行排序，最後按照輪詢的方式發給每一個消費線程。

18.簡述Kafka的日誌目錄結構？

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

每個partition一個文件夾，包含四類文件

.index
.log
.timeindex
leader-epoch-checkpoint

.index .log .timeindex 三個文件成對出現前綴爲上一個segment的最後一個消息的偏移 log文件中保存了所有的消息 index文件中保存了稀疏的相對偏移的索引 timeindex保存的則是時間索引

leader-epoch-checkpoint中保存了每一任leader開始寫入消息時的offset 會定時更新,follower被選爲leader時會根據這個確定哪些消息可用

19.如果我指定了一個offset，Kafka Controller怎麼查找到對應的消息？

先二分查找獲取對應index索引文件，獲取到對應的物理offset
拿着物理offset去log數據文件順序查找對應消息
返回查找到的消息

20. 聊一聊Kafka Controller的作用？

https://blog.csdn.net/u013256816/article/details/80865540

負責管理集羣broker的上下線，所有topic的分區副本分配和leader選舉等工作

在Kafka集羣中會有一個或者多個broker，其中有一個broker會被選舉爲控制器（Kafka Controller），它負責管理整個集羣中所有分區和副本的狀態。當某個分區的leader副本出現故障時，由控制器負責爲該分區選舉新的leader副本。當檢測到某個分區的ISR集合發生變化時，由控制器負責通知所有broker更新其元數據信息。當使用kafka-topics.sh腳本爲某個topic增加分區數量時，同樣還是由控制器負責分區的重新分配。

21. Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？

partition leader（ISR）

kafka controller（先到先得）

當broker啓動時，會嘗試會去創建/controller節點，創建成功即成爲controller。如果該controller死亡，/controller節點會釋放，由新的broker創建此節點成爲新的controller

22. 失效副本是指什麼？有那些應對措施？

不能及時與leader同步，暫時踢出ISR，等其追上leader之後再重新加入

ISR是由leader維護，follower從leader同步數據有一些延遲（包括延遲時間replica.lag.time.max.ms和延遲條數replica.lag.max.messages兩個維度, 當前最新的版本0.10.x中只支持replica.lag.time.max.ms這個維度），任意一個超過閾值都會把follower剔除出ISR, 存入**OSR（Outof-Sync Replicas）**列表，新加入的follower也會先存放在OSR中。AR=ISR+OSR。

osr中的副本，如果與leader通信後，會嘗試與leader同步，同步的策略是首先將當前記錄的hw之後的消息刪除，然後與leader同步，當與leader基本同步之後（存儲的消息的offset大於當前isr中的hw），就重新回到isr之中

23.Kafka的那些設計讓它有如此高的性能？

分區，順序寫磁盤，0-copy

24.Kafka消息數據積壓，Kafka消費能力不足怎麼處理？

如果是Kafka消費能力不足，則可以考慮增加Topic的分區數，並且同時提升消費組的消費者數量，消費者數=分區數。（兩者缺一不可）
如果是下游的數據處理不及時：提高每批次拉取的數量。批次拉取數據過少（拉取數據/處理時間<生產速度），使處理的數據小於生產的數據，也會造成數據積壓。

25.Kafka中數據量計算

每天總數據量100g，每天產生1億條日誌， 10000萬/24/60/60=1150條/每秒鐘

平均每秒鐘：1150條

低谷每秒鐘：400條

高峯每秒鐘：1150條*（2-20倍）=2300條-23000條

每條日誌大小：0.5k-2k

每秒多少數據量：2.3M-20MB

26. Kafka的ISR副本同步隊列

ISR（In-Sync Replicas），副本同步隊列。ISR中包括Leader和Follower。如果Leader進程掛掉，會在ISR隊列中選擇一個服務作爲新的Leader。有replica.lag.max.messages（延遲條數）和replica.lag.time.max.ms（延遲時間）兩個參數決定一臺服務是否可以加入ISR副本隊列，在0.10版本移除了replica.lag.max.messages參數，防止服務頻繁的進去隊列。

任意一個維度超過閾值都會把Follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的Follower也會先存放在OSR中。

27.Kafka丟不丟數據

Ack=0，相當於異步發送，消息發送完畢即offset增加，繼續生產。

Ack=1，leader收到leader replica 對一個消息的接受ack才增加offset，然後繼續生產。

Ack=-1，leader收到所有replica 對一個消息的接受ack才增加offset，然後繼續生產。

28.多少個Topic

通常情況：多少個日誌類型就多少個Topic。也有對日誌類型進行合併的。

29.Kakfa分區數

分區數並不是越多越好，一般分區數不要超過集羣機器數量。分區數越多佔用內存越大（ISR等），一個節點集中的分區也就越多，當它宕機的時候，對系統的影響也就越大。

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

30.Kafka監控

公司自己開發的監控器；

開源的監控器：KafkaManager,KafkaMonitor,Kafka Eagle

31. Kafka的硬盤大小

每天的數據量*7天

32.Kafka的日誌保存時間

7天

33.Kafka的機器數量

Kafka機器數量=2*（峯值生產速度*副本數/100）+1

34.Kafka壓測

Kafka官方自帶壓力測試腳本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka壓測時，可以查看到哪個地方出現了瓶頸（CPU，內存，網絡IO）。一般都是網絡IO達到瓶頸。