Kafka可以說是必知必會的了，首先面試大數據崗位的時候必問kafka，甚至現在java開發崗位也會問到kafka一些消息隊列相關的知識點。先來看看有哪些最新的Kafka相關面試點：
一、基礎摸底
1.1、你們Kafka集羣的硬盤一共多大？有多少臺機器？日誌保存多久？用什麼監控的？
1.2、Kafka分區數、副本數和topic數量多少比較合適？
1.3、Kafka中的HW、LEO、ISR、AR分別是什麼意思？
1.4、Kafka中的消息有序嗎？怎麼實現的？
1.5、topic的分區數可以增加或減少嗎？爲什麼？
1.6、你知道kafka是怎麼維護offset的嗎？
1.7、你們是怎麼對Kafka進行壓測的？
二、感覺還不錯，接着深入考察
2.1、創建或者刪除topic時，Kafka底層執行了哪些邏輯？
2.2、你瞭解Kafka的日誌目錄結構嗎？
2.3、Kafka中需要用到選舉嗎？對應選舉策略是什麼？
2.4、追問，聊聊你對ISR的瞭解？
2.5、聊聊Kafka分區分配策略？
2.6、當Kafka消息數據出現了積壓，應該怎麼處理？
2.7、Kafka是怎麼實現Exactly Once的？
2.8、追問、談談你對Kafka冪等性的理解？
2.9、你對Kafka事務瞭解多少？
2.10、Kafka怎麼實現如此高的讀寫效率？
三、侃侃而談
3.1、說說你常用的broker參數優化？
3.2、那怎麼進行producer優化呢？
總結最準確的答案如下：
一、基礎摸底
1.1、你們Kafka集羣的硬盤一共多大？有多少臺機器？日誌保存多久？用什麼監控的？
這裏考察應試者對kafka實際生產部署的能力，也是爲了驗證能力的真實程度，如果這個都答不好，那可能就不會再繼續下去了。
一般企業判斷這些指標有一個標準：
集羣硬盤大小：每天的數據量/70%*日誌保存天數；
機器數量：Kafka 機器數量=2*（峯值生產速度*副本數/100）+1；
日誌保存時間：可以回答保存7天；
監控Kafka：一般公司有自己開發的監控器，或者cdh配套的監控器，另外還有一些開源的監控器：kafkaeagle、KafkaMonitor、KafkaManager。
1.2、Kafka分區數、副本數和topic數量多少比較合適？
首先要知道分區數並不是越多越好，一般分區數不要超過集羣機器數量。分區數越多佔用內存越大 （ISR 等），一個節點集中的分區也就越多，當它宕機的時候，對系統的影響也就越大。
分區數一般設置爲：3-10 個。
副本數一般設置爲：2-3個。
topic數量需要根據日誌類型來定，一般有多少個日誌類型就定多少個topic，不過也有對日誌類型進行合併的。
1.3、Kafka中的HW、LEO、ISR、AR分別是什麼意思？
LEO：每個副本的最後一條消息的offset
HW：一個分區中所有副本最小的offset
ISR：與leader保持同步的follower集合
AR：分區的所有副本
1.4、Kafka中的消息有序嗎？怎麼實現的？
kafka無法保證整個topic多個分區有序，但是由於每個分區（partition）內，每條消息都有一個offset，故可以保證分區內有序。
1.5、topic的分區數可以增加或減少嗎？爲什麼？
topic的分區數只能增加不能減少，因爲減少掉的分區也就是被刪除的分區的數據難以處理。
增加topic命令如下：
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter \
--topic topic-config --partitions 3
關於topic還有一個面試點要知道：消費者組中的消費者個數如果超過topic的分區，那麼就會有消費者消費不到數據。
1.6、你知道kafka是怎麼維護offset的嗎？
1.維護offset的原因：由於consumer在消費過程中可能會出現斷電宕機等故障，consumer恢復後，需要從故障前的位置的繼續消費，所以consumer需要實時記錄自己消費到了哪個offset，以便故障恢復後繼續消費。
2. 維護offset的方式：Kafka 0.9版本之前，consumer默認將offset保存在Zookeeper中，從0.9版本開始，consumer默認將offset保存在Kafka一個內置的topic中，該topic爲**__consumer_offsets**。
3.需要掌握的關於offset的常識：消費者提交消費位移時提交的是當前消費到的最新消息的offset+1而不是offset。
1.7、你們是怎麼對Kafka進行壓測的？
Kafka官方自帶了壓力測試腳本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）， Kafka 壓測時，可以查看到哪個地方出現了瓶頸（CPU，內存，網絡 IO），一般都是網絡 IO 達到瓶頸。
二、感覺還不錯，接着深入考察
2.1、創建或者刪除topic時，Kafka底層執行了哪些邏輯？
以創建topic爲例，比如我們執行如下命令，創建了一個叫做csdn的分區數爲1，副本數爲3的topic。
bin/kafka-topics.sh --zookeeper node:2181 --create \
--replication-factor 3 --partitions 1 --topic csdn
這行命令，在kafka底層需要經過三個步驟來處理：
1. 在zookeeper中的/brokers/topics節點下創建一個新的topic節點，如：/brokers/topics/csdn；
2. 然後會觸發Controller的監聽程序；
3. 最後kafka Controller負責topic的創建工作，並更新metadata cache，到這裏topic創建完成。
2.2、你瞭解Kafka的日誌目錄結構嗎？
1. 每個 Topic 都可以分爲一個或多個 Partition，Topic其實是比較抽象的概念，但是 Partition是比較具體的東西；
2. 其實Partition 在服務器上的表現形式就是一個一個的文件夾，由於生產者生產的消息會不斷追加到log文件末尾，爲防止log文件過大導致數據定位效率低下，Kafka採取了分片和索引機制，將每個partition分爲多個segment；
3. 每組 Segment 文件又包含 .index 文件、.log 文件、.timeindex 文件（早期版本中沒有）三個文件。.log和.index文件位於一個文件夾下，該文件夾的命名規則爲：topic名稱+分區序號。例如，csdn這個topic有2個分區，則其對應的文件夾爲csdn-0,csdn-1；
4. log 文件就是實際存儲 Message 的地方，而 index 和 timeindex 文件爲索引文件，用於檢索消息
2.3、Kafka中需要用到選舉嗎？對應選舉策略是什麼？
一共有兩處需要用到選舉，首先是partition的leader，用到的選舉策略是ISR；然後是kafka Controller，用先到先得的選舉策略。
2.4、追問，聊聊你對ISR的瞭解？
ISR就是kafka的副本同步隊列，全稱是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 中。
2.5、聊聊Kafka分區分配策略？
在 Kafka 內部存在三種默認的分區分配策略：Range ， RoundRobin以及0.11.x版本引入的Sticky。Range 是默認策略。Range 是對每個 Topic 而言的（即一個 Topic 一個 Topic 分），首先 對同一個 Topic 裏面的分區按照序號進行排序，並對消費者按照字母順序進行排序。然後用 Partitions 分區的個數除以消費者線程的總數來決定每個消費者線程消費幾個分區。如果除不盡，那麼前面幾個消費者線程將會多消費一個分區。
三種分區分配策略詳見文章：深入分析Kafka架構（三）：消費者消費方式、分區分配策略（Range分配策略、RoundRobin分配策略、Sticky分配策略）、offset維護
文中對三種分區分配策略舉例並進行了非常詳細的對比，值得一看。
2.6、當Kafka消息數據出現了積壓，應該怎麼處理？
數據積壓主要可以從兩個角度去分析：
1. 如果是 Kafka 消費能力不足，則可以考慮增加 Topic 的分區數，並且同時提升消費 組的消費者數量，消費者數=分區數。（兩者缺一不可）
2. 如果是下游的數據處理不及時：提高每批次拉取的數量。如果是因爲批次拉取數據過少（拉取 數據/處理時間<生產速度），也會使處理的數據小於生產的數據，造成數據積壓。
2.7、Kafka是怎麼實現Exactly Once的？
在實際情況下，我們對於某些比較重要的消息，需要保證exactly once語義，也就是保證每條消息被髮送且僅被髮送一次，不能重複。在0.11版本之後，Kafka引入了冪等性機制（idempotent），配合acks = -1時的at least once語義，實現了producer到broker的exactly once語義。
idempotent + at least once = exactly once
使用時，只需將enable.idempotence屬性設置爲true，kafka自動將acks屬性設爲-1。
2.8、追問、談談你對Kafka冪等性的理解？
Producer的冪等性指的是當發送同一條消息時，數據在 Server 端只會被持久化一次，數據不丟不重，但是這裏的冪等性是有條件的：
1. 只能保證 Producer 在單個會話內不丟不重，如果 Producer 出現意外掛掉再重啓是 無法保證的。因爲冪等性情況下，是無法獲取之前的狀態信息，因此是無法做到跨會話級別的不丟不重。
2. 冪等性不能跨多個 Topic-Partition，只能保證單個 Partition 內的冪等性，當涉及多個Topic-Partition 時，這中間的狀態並沒有同步。
2.9、你對Kafka事務瞭解多少？
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生命週期不同，同一事務的消息可能會出現重啓後被刪除的情況。
2.10、Kafka怎麼實現如此高的讀寫效率？
1. 首先kafka本身是分佈式集羣，同時採用了分區技術，具有較高的併發度；
2. 順序寫入磁盤，Kafka 的 producer 生產數據，要寫入到 log 文件中，寫的過程是一直追加到文件末端，爲順序寫。
官網有數據表明，同樣的磁盤，順序寫能到 600M/s，而隨機寫只有 100K/s。這 與磁盤的機械機構有關，順序寫之所以快，是因爲其省去了大量磁頭尋址的時間。
3. 零拷貝技術
三、侃侃而談
3.1、說說你常用的broker參數優化？
1. 網絡和IO操作線程配置優化
# broker 處理消息的最大線程數（默認爲 3）
num.network.threads=cpu 核數+1
# broker 處理磁盤 IO 的線程數
num.io.threads=cpu 核數*2
2. log數據文件策略
# 每間隔 1 秒鐘時間，刷數據到磁盤
log.flush.interval.ms=1000
3. 日誌保存策略
# 保留三天，也可以更短 （log.cleaner.delete.retention.ms）
log.retention.hours=72
4. replica相關配置
offsets.topic.replication.factor:3
# 這個參數指新創建一個 topic 時，默認的 Replica 數量,Replica 過少會影響數據的可用性，太多則會白白浪費存儲資源，一般建議在 2~3 爲宜
3.2、那怎麼進行producer優化呢？
buffer.memory:33554432 (32m)
# 在 Producer 端用來存放尚未發送出去的 Message 的緩衝區大小。緩衝區滿了之後可以選擇阻塞發送或拋出異常，由 block.on.buffer.full 的配置來決定。
compression.type:none
#默認發送不進行壓縮，這裏其實可以配置一種適合的壓縮算法，可以大幅度的減緩網絡壓力和Broker 的存儲壓力。
往期推薦 點擊標題跳轉
2、HBase原理 | HBase Compaction介紹與參數調優
4、MapReduce Shuffle 和 Spark Shuffle 結業篇
