本文是根據平時面試以及網上資源進行的整理。希望對小伙伴們面試有幫助。
消息隊列的作用和使用場景
通過異步處理提高響應時間，削峰填谷：
場景：數據比較集中且實時要求不是太高，如果同步處理，假如業務高峰需要4台服務支撐，那么在業務高峰過了之后，就會出現資源閑置，如果引入消息隊列的話，將數據放到消息隊列后直接返回成功，提升了響應時間，真正的業務在消息隊列后面消費處理，可能2台服務就能夠支撐的住，而且流量更加均勻。
降低系統間的耦合度：
場景：數據不止一方依賴，可能多個系統都需要這份數據，如果由發送方直接調用，那么如果新增業務也依賴數據，就得修改發送方代碼；使用消息隊列的話，將發送方和接收方解耦，發送方將數據扔到消息隊列，依賴方可根據需求消費處理。
使用消息隊列會帶來哪些問題？
系統復雜度提高，可用性降低，不僅需要考慮消息隊列的可用性，還要考慮數據的一致性
如何做的消息隊列選型，為什么選擇kafka？
kafka和rocketmq吞吐量可達百萬級，比activemq、rabbitmq要高一個數量級
kafka和rocketmq都是分布式架構，高可用
kafka和rocketmq都是毫秒級低延時，rocketmq甚至到微秒級
rocketmq不支持隊列層面的廣播，kafka的consumer group支持組間廣播，組內負載均衡
kafka可能會產生消息重復，業務做好冪等
kafka相關概念與消費模型
broker：kafka集群中的一個節點
topic：主題是kafka的邏輯上的隊列
partition：一個topic可以包含一個或多個partition，每個partition的消息數據都是單獨存儲的，offset也是單獨維護的，partition內部消息有序
partition復制因子：一個topic的所有分區會分布到各個broker上，允許設置復制因子使分區可以在其他節點上留存備份，在主分區所在broker宕機時，可以作為新的主分區繼續提供服務
consumer group：一個topic可以有消費者組消費消息，kafka為每個消費者組單獨管理每個分區的消費偏移量offset，消費者組間是廣播模式，對於一個消費者組內是負載均衡，即一條消息可以被多個消費者組消費，只能被一個消費者組內的其中一個消費者消費；消費者組內的每個成員負責一定數量的分區，當消費者組內的消費者發生變動時，會觸發分區的重平衡
pull消費模型：消費者向負責分區主動拉取消息，分區的消費偏移量通過一個默認的topic來記錄，也可以顯示指定
pull模型的優點：
消費速度可以由消費者自由控制
逐條消費或者批量消費可以由消費者自由控制
broker設計更簡單
kafka的消息存儲
kafka的消息存儲在磁盤上，一個kafka topic分為一個或多個partition，每個partition單獨存儲自己的消息數據
partition將數據記錄到.log文件中，為了避免文件過大影響查詢效率，將文件分段處理
記錄消息到.log文件中的同時，會記錄消息offset和物理偏移地址的映射作為索引，提升查找性能；
這個索引並不是按消息的順序依次記錄的，而是每隔一定字節的數據記錄一條索引，降低了索引文件的大小
kafka查找消息時，只需要根據文件名和offset進行二分查找，找到對應的日志分段后，查找.index文件找到物理偏移地址，然后查.log讀取消息內容
消費組與分區重平衡
當有新的消費者加入到消費者組時，原本的分區就需要重新分配；比如一個topic有30個分區，原本只有兩個消費者，每人負責15個分區，當新加入一個消費者時，並沒有分區可以給他消費，只能是將30個分區重新分配。
每個消費者組都會有一個broker負責協調（稱為group coordinator），各個消費者通過發送心跳的方式向組協調者同步狀態，當有消費者一定時間沒有給組協調者發送心跳或者有新的消費者加入到消費者組時，就會觸發消費組的重平衡操作。
新加入消費者觸發重平衡：
1.新加入消費者向組協調者發送joinGroup請求，攜帶訂閱的topic信息
2.此后組協調者收到組內其他消費者的心跳請求時，在響應中告訴消費者要重平衡
3.組內原有消費者會重新發送joinGroup請求到組協調者
4.組協調者根據發送joinGroup請求的先后選出消費者leader，將topic和分區信息響應給各個消費者
5.被選為leader的消費者將分區分配好
6.各消費者發送SyncGroup請求給組協調者請求新分配好的分區信息，其中消費者leader會攜帶分配好的分區信息
7.組協調者將各個消費者負責的分區信息響應給消費者，重平衡完成
消費者主動離開導致重平衡
1.消費者發送leaveGroup請求給組協調者
2.此后組協調者收到組內其他消費者的心跳請求時，在響應中告訴消費者要重平衡
3.消費者會重新發送joinGroup請求到組協調者
4.組協調者根據發送joinGroup請求的先后選出消費者leader，將topic和分區信息響應給各個消費者
5.被選為leader的消費者將分區分配好
6.各消費者發送SyncGroup請求給組協調者請求新分配好的分區信息，其中消費者leader會攜帶分配好的分區信息
7.組協調者將各個消費者負責的分區信息響應給消費者，重平衡完成
消費者失去心跳導致重平衡
1.消費者一定時間內沒有發送心跳信息給組協調者
2.此后組協調者收到組內其他消費者的心跳請求時，在響應中告訴消費者要重平衡
3.消費者會重新發送joinGroup請求到組協調者
4.組協調者根據發送joinGroup請求的先后選出消費者leader，將topic和分區信息響應給各個消費者
5.被選為leader的消費者將分區分配好
6.各消費者發送SyncGroup請求給組協調者請求新分配好的分區信息，其中消費者leader會攜帶分配好的分區信息
7.組協調者將各個消費者負責的分區信息響應給消費者，重平衡完成
kafka如何保證不丟失消息？
-
復制因子：創建topic的時候指定復制因子大於1時，一個分區被分配到一個broker上，同時會在其他broker上維護一個分區副本；
-
isr列表：分區及其副本分別為leader和follower，leader對外提供讀寫服務，follower會向leader發送同步請求，拉取最新的數據，如果follower和leader的消息差距保持在一定范圍之內，那么這個follower在isr列表內；當分區leader所在broker宕機，會從isr列表中選舉一個follower作為新的leader提供服務
-
通過kafka的acks參數可以控制消息的發送行為，acks可選的值有0、1、all；當設置為0時，生產者消息發送成功即為成功，不關心是否寫入到磁盤及后續操作；當設置為1時，消息發送到分區leader后寫入磁盤即為成功；當設置為all時，消息發送到分區leader並寫入磁盤后，同步給isr列表中的所有分區副本后即為成功
kafka高可用
broker啟動會嘗試向zookeeper創建臨時節點：/controller，第一個broker選舉成功成為集群的controller，其余節點都會在/controller注冊watcher監控controller狀態；當controller掛掉，所有broker感知到，重新嘗試選舉controller
controller節點通過zookeeper監控各broker狀態，如果由broker掛掉，controller負責從其負責的leader分區的isr列表中選舉一個作為新的leader
kafka副本和leader選舉
kafka高性能原因
零拷貝、利用操作系統頁緩存、磁盤順序寫
kafka零拷貝原理
分區、分段、建立索引
生產者、消費者批處理
Kafka中的ISR、AR又代表什么？ISR的伸縮又指什么
ISR:In-Sync Replicas 副本同步隊列
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。
** Kafka中的HW、LEO、LSO、LW等分別代表什么？**
HW:High Watermark 高水位，取一個partition對應的ISR中最小的LEO作為HW，consumer最多只能消費到HW所在的位置上一條信息
LEO:LogEndOffset 當前日志文件中下一條待寫信息的offset
HW/LEO這兩個都是指最后一條的下一條的位置而不是指最后一條的位置
LSO:Last Stable Offset 對未完成的事務而言，LSO 的值等於事務中第一條消息的位置(firstUnstableOffset)，對已完成的事務而言，它的值同 HW 相同
LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值
Kafka中是怎么體現消息順序性的？
kafka每個partition中的消息在寫入時都是有序的，消費時，每個partition只能被每一個group中的一個消費者消費，保證了消費時也是有序的。
整個topic不保證有序。如果為了保證topic整個有序，那么將partition調整為1.
Kafka中的分區器、序列化器、攔截器是否了解？它們之間的處理順序是什么？
攔截器->序列化器->分區器
Kafka生產者客戶端的整體結構是什么樣子的？
Kafka生產者客戶端中使用了幾個線程來處理？分別是什么？
2個，主線程和Sender線程。主線程負責創建消息，然后通過分區器、序列化器、攔截器作用之后緩存到累加器RecordAccumulator中。Sender線程負責將RecordAccumulator中消息發送到kafka中.
Kafka的舊版Scala的消費者客戶端的設計有什么缺陷？
消費組中的消費者個數如果超過topic的分區，那么就會有消費者消費不到數據”這句話是否正確？如果不正確，那么有沒有什么hack的手段？
不正確，通過自定義分區分配策略，可以將一個consumer指定消費所有partition。
消費者提交消費位移時提交的是當前消費到的最新消息的offset還是offset+1?
offset+1
有哪些情形會造成重復消費？
消費者消費后沒有commit offset(程序崩潰/強行kill/消費耗時/自動提交偏移情況下unscrible)
那些情景下會造成消息漏消費？
消費者沒有處理完消息 提交offset(自動提交偏移 未處理情況下程序異常結束)
KafkaConsumer是非線程安全的，那么怎么樣實現多線程消費？
1.在每個線程中新建一個KafkaConsumer
2.單線程創建KafkaConsumer，多個處理線程處理消息（難點在於是否要考慮消息順序性，offset的提交方式）
簡述消費者與消費組之間的關系
消費者從屬與消費組，消費偏移以消費組為單位。每個消費組可以獨立消費主題的所有數據，同一消費組內消費者共同消費主題數據，每個分區只能被同一消費組內一個消費者消費。
當你使用kafka-topics.sh創建（刪除）了一個topic之后，Kafka背后會執行什么邏輯？
創建:在zk上/brokers/topics/下節點 kafkabroker會監聽節點變化創建主題
刪除:調用腳本刪除topic會在zk上將topic設置待刪除標志，kafka后台有定時的線程會掃描所有需要刪除的topic進行刪除
topic的分區數可不可以增加？如果可以怎么增加？如果不可以，那又是為什么？
可以
topic的分區數可不可以減少？如果可以怎么減少？如果不可以，那又是為什么？
不可以
創建topic時如何選擇合適的分區數？
根據集群的機器數量和需要的吞吐量來決定適合的分區數
Kafka目前有那些內部topic，它們都有什么特征？各自的作用又是什么？
consumer_offsets 以下划線開頭，保存消費組的偏移
優先副本是什么？它有什么特殊的作用？
優先副本 會是默認的leader副本 發生leader變化時重選舉會優先選擇優先副本作為leader
Kafka有哪幾處地方有分區分配的概念？簡述大致的過程及原理
創建主題時
如果不手動指定分配方式 有兩種分配方式
消費組內分配
簡述Kafka的日志目錄結構
每個partition一個文件夾，包含四類文件.index .log .timeindex leader-epoch-checkpoint
.index .log .timeindex 三個文件成對出現 前綴為上一個segment的最后一個消息的偏移 log文件中保存了所有的消息 index文件中保存了稀疏的相對偏移的索引 timeindex保存的則是時間索引
leader-epoch-checkpoint中保存了每一任leader開始寫入消息時的offset 會定時更新
follower被選為leader時會根據這個確定哪些消息可用
Kafka中有那些索引文件？
如上
如果我指定了一個offset，Kafka怎么查找到對應的消息？
1.通過文件名前綴數字x找到該絕對offset 對應消息所在文件
2.offset-x為在文件中的相對偏移
3.通過index文件中記錄的索引找到最近的消息的位置
4.從最近位置開始逐條尋找
如果我指定了一個timestamp，Kafka怎么查找到對應的消息？
原理同上 但是時間的因為消息體中不帶有時間戳 所以不精確
聊一聊你對Kafka的Log Retention的理解
kafka留存策略包括 刪除和壓縮兩種
刪除: 根據時間和大小兩個方式進行刪除 大小是整個partition日志文件的大小
超過的會從老到新依次刪除 時間指日志文件中的最大時間戳而非文件的最后修改時間
壓縮: 相同key的value只保存一個 壓縮過的是clean 未壓縮的dirty 壓縮之后的偏移量不連續 未壓縮時連續
聊一聊你對Kafka的Log Compaction的理解
聊一聊你對Kafka底層存儲的理解（頁緩存、內核層、塊層、設備層）
聊一聊Kafka的延時操作的原理
聊一聊Kafka控制器的作用
消費再均衡的原理是什么？（提示：消費者協調器和消費組協調器）
Kafka中的冪等是怎么實現的
pid+序號實現，單個producer內冪等
Kafka中的事務是怎么實現的（這題我去面試6家被問4次，照着答案念也要念十幾分鍾，面試官簡直湊不要臉。實在記不住的話…只要簡歷上不寫精通Kafka一般不會問到，我簡歷上寫的是“熟悉Kafka，了解RabbitMQ….”）
Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？
失效副本是指什么？有那些應對措施？
多副本下，各個副本中的HW和LEO的演變過程
為什么Kafka不支持讀寫分離？
Kafka在可靠性方面做了哪些改進？（HW, LeaderEpoch）
Kafka中怎么實現死信隊列和重試隊列？
Kafka中的延遲隊列怎么實現（這題被問的比事務那題還要多！！！聽說你會Kafka，那你說說延遲隊列怎么實現？）
Kafka中怎么做消息審計？
Kafka中怎么做消息軌跡？
Kafka中有那些配置參數比較有意思？聊一聊你的看法
Kafka中有那些命名比較有意思？聊一聊你的看法
Kafka有哪些指標需要着重關注？
生產者關注MessagesInPerSec、BytesOutPerSec、BytesInPerSec 消費者關注消費延遲Lag
怎么計算Lag？(注意read_uncommitted和read_committed狀態下的不同)
參考 如何監控kafka消費Lag情況
Kafka的那些設計讓它有如此高的性能？
零拷貝，頁緩存，順序寫
Kafka有什么優缺點？
還用過什么同質類的其它產品，與Kafka相比有什么優缺點？
為什么選擇Kafka?
吞吐量高，大數據消息系統唯一選擇。
在使用Kafka的過程中遇到過什么困難？怎么解決的？
怎么樣才能確保Kafka極大程度上的可靠性？
聲明：本號所有文章除特殊注明，都為原創，公眾號讀者擁有優先閱讀權，未經作者本人允許不得轉載，否則追究侵權責任。
關注我的公眾號，后台回復【JAVAPDF】獲取200頁面試題！
5萬人關注的大數據成神之路，不來了解一下嗎？
5萬人關注的大數據成神之路，真的不來了解一下嗎？
5萬人關注的大數據成神之路，確定真的不來了解一下嗎？
歡迎您關注《大數據成神之路》
