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