1. 什么是Apache Kafka?

答：Apache Kafka是一個發(fā)布 - 訂閱開源消息代理應用程序。這個消息傳遞應用程序是用“scala”編碼的堕伪。基本上，這個項目是由Apache軟件啟動的卧波。Kafka的設(shè)計模式主要基于事務日志設(shè)計。

2. Kafka中有哪幾個組件?

主題：Kafka主題是一堆或一組消息庇茫。

生產(chǎn)者：在Kafka港粱，生產(chǎn)者發(fā)布通信以及向Kafka主題發(fā)布消息。

消費者：Kafka消費者訂閱了一個主題，并且還從主題中讀取和處理消息查坪。

經(jīng)紀人：在管理主題中的消息存儲時寸宏，我們使用Kafka Brokers。

3. 解釋偏移的作用偿曙。

答：給分區(qū)中的消息提供了一個順序ID號氮凝，我們稱之為偏移量。因此望忆，為了唯一地識別分區(qū)中的每條消息罩阵，我們使用這些偏移量。

4. 什么是消費者組启摄？

答：消費者組的概念是Apache Kafka獨有的稿壁。基本上鞋仍，每個Kafka消費群體都由一個或多個共同消費一組訂閱主題的消費者組成常摧。

5. ZooKeeper在Kafka中的作用是什么？

答：Apache Kafka是一個使用Zookeeper構(gòu)建的分布式系統(tǒng)威创。雖然落午，Zookeeper的主要作用是在集群中的不同節(jié)點之間建立協(xié)調(diào)。但是肚豺，如果任何節(jié)點失敗溃斋，我們還使用Zookeeper從先前提交的偏移量中恢復，因為它做周期性提交偏移量工作吸申。

6. 沒有ZooKeeper可以使用Kafka嗎梗劫？

答：繞過Zookeeper并直接連接到Kafka服務器是不可能的，所以答案是否定的截碴。如果以某種方式梳侨，使ZooKeeper關(guān)閉，則無法為任何客戶端請求提供服務日丹。

7. 為什么Kafka技術(shù)很重要走哺？

答：Kafka有一些優(yōu)點，因此使用起來很重要：

高吞吐量：我們在Kafka中不需要任何大型硬件哲虾，因為它能夠處理高速和大容量數(shù)據(jù)丙躏。此外，它還可以支持每秒數(shù)千條消息的消息吞吐量束凑。
低延遲：Kafka可以輕松處理這些消息晒旅，具有毫秒級的極低延遲，這是大多數(shù)新用例所要求的汪诉。
容錯：Kafka能夠抵抗集群中的節(jié)點/機器故障废恋。
耐久性：由于Kafka支持消息復制，因此消息永遠不會丟失。這是耐久性背后的原因之一鱼鼓。
可擴展性：卡夫卡可以擴展孝常，而不需要通過添加額外的節(jié)點而在運行中造成任何停機。

8. 是什么確保了Kafka中服務器的負載平衡蚓哩？

答：由于領(lǐng)導者的主要角色是執(zhí)行分區(qū)的所有讀寫請求的任務构灸，而追隨者被動地復制領(lǐng)導者。因此岸梨，在領(lǐng)導者失敗時喜颁，其中一個追隨者接管了領(lǐng)導者的角色〔芾基本上半开，整個過程可確保服務器的負載平衡。

9. 副本和ISR扮演什么角色赃份？

答：基本上寂拆，復制日志的節(jié)點列表就是副本。特別是對于特定的分區(qū)抓韩。但是纠永，無論他們是否扮演領(lǐng)導者的角色，他們都是如此谒拴。
此外尝江，ISR指的是同步副本。在定義ISR時英上，它是一組與領(lǐng)導者同步的消息副本炭序。

10. 為什么Kafka的復制至關(guān)重要？

答：由于復制苍日，我們可以確保發(fā)布的消息不會丟失惭聂，并且可以在發(fā)生任何機器錯誤、程序錯誤或頻繁的軟件升級時使用相恃。

11. 如果副本長時間不在ISR中辜纲，這意味著什么？

答：簡單地說豆茫，這意味著跟隨者不能像領(lǐng)導者收集數(shù)據(jù)那樣快速地獲取數(shù)據(jù)侨歉。

12. 在生產(chǎn)者中屋摇，何時發(fā)生QueueFullException揩魂？

答：每當Kafka生產(chǎn)者試圖以代理的身份在當時無法處理的速度發(fā)送消息時，通常都會發(fā)生QueueFullException炮温。但是火脉，為了協(xié)作處理增加的負載，用戶需要添加足夠的代理，因為生產(chǎn)者不會阻止倦挂。

13. Apache Kafka是分布式流處理平臺嗎畸颅？如果是，你能用它做什么方援？

答：毫無疑問没炒，Kafka是一個流處理平臺。它可以幫助：
1.輕松推送記錄

2.可以存儲大量記錄犯戏，而不會出現(xiàn)任何存儲問題
3.它還可以在記錄進入時對其進行處理送火。

14. 你能用Kafka做什么？

答：它可以以多種方式執(zhí)行先匪，例如：

為了在兩個系統(tǒng)之間傳輸數(shù)據(jù)种吸，我們可以用它構(gòu)建實時的數(shù)據(jù)流管道。
另外呀非，我們可以用Kafka構(gòu)建一個實時流處理平臺坚俗，它可以對數(shù)據(jù)快速做出反應。

15. 在Kafka集群中保留期的目的是什么岸裙？

答：保留期限保留了Kafka群集中的所有已發(fā)布記錄猖败。它不會檢查它們是否已被消耗。此外降允，可以通過使用保留期的配置設(shè)置來丟棄記錄辙浑。而且，它可以釋放一些空間拟糕。

16. 解釋Kafka可以接收的消息最大為多少判呕？

答：Kafka可以接收的最大消息大小約為1000000字節(jié)。
問題24：傳統(tǒng)的消息傳遞方法有哪些類型送滞？
答：基本上侠草，傳統(tǒng)的消息傳遞方法有兩種，如：

排隊：這是一種消費者池可以從服務器讀取消息并且每條消息轉(zhuǎn)到其中一個消息的方法犁嗅。
發(fā)布-訂閱：在發(fā)布-訂閱中边涕，消息被廣播給所有消費者。

17. ISR在Kafka環(huán)境中代表什么褂微？

答：ISR指的是同步副本功蜓。這些通常被分類為一組消息副本，它們被同步為領(lǐng)導者宠蚂。

18. 什么是Kafka中的地域復制式撼？

答：對于我們的集群，Kafka MirrorMaker提供地理復制求厕≈。基本上扰楼，消息是通過MirrorMaker跨多個數(shù)據(jù)中心或云區(qū)域復制的。因此美浦，它可以在主動/被動場景中用于備份和恢復弦赖；也可以將數(shù)據(jù)放在離用戶更近的位置，或者支持數(shù)據(jù)位置要求浦辨。

19. 解釋多租戶是什么蹬竖？

答：我們可以輕松地將Kafka部署為多租戶解決方案。但是流酬，通過配置主題可以生成或使用數(shù)據(jù)案腺，可以啟用多租戶。此外康吵，它還為配額提供操作支持劈榨。

20. Kafka中的數(shù)據(jù)日志是什么？

答：我們知道晦嵌，在Kafka中同辣，消息會保留相當長的時間。此外惭载，消費者還可以根據(jù)自己的方便進行閱讀旱函。盡管如此，有一種可能的情況是描滔，如果將Kafka配置為將消息保留24小時棒妨，并且消費者可能停機超過24小時，則消費者可能會丟失這些消息含长。但是券腔，我們?nèi)匀豢梢詮纳洗我阎钠浦凶x取這些消息，但僅限于消費者的部分停機時間僅為60分鐘的情況拘泞。此外纷纫，關(guān)于消費者從一個話題中讀到什么，Kafka不會保持狀態(tài)陪腌。

21. Apache Kafka的缺陷

答：Kafka的局限性是：

沒有完整的監(jiān)控工具集
消息調(diào)整的問題
不支持通配符主題選擇
速度問題

22. 什么是kafka 消費者重平衡辱魁？會造成什么影響？

重平衡本質(zhì)上是一種協(xié)議诗鸭，規(guī)定了 消費者組下的所有消費者染簇，按照什么策略消費 Topic

就是 給消費組 中的每一個消費者分配消費 任務的過程。

重平衡的發(fā)生在啟動一個消費者組前强岸，但是在某些情況下锻弓，會正在運行消費的時，再次發(fā)生请唱，可能會導致整個集群的暫時性的癱瘓弥咪，影響kafka的高可用。

23. 消費者重平衡的發(fā)生時機十绑？

1. 訂閱主題數(shù)發(fā)生變化聚至，這種一般發(fā)生在業(yè)務改變，數(shù)據(jù)一定變化

2. 主題的分區(qū)發(fā)生變化本橙， 啟動集群前設(shè)置分區(qū)數(shù)扳躬， 之后調(diào)節(jié)，也是人為調(diào)節(jié)甚亭，可以在半夜

3. 消費端消費組成員的變化贷币， 這個原因產(chǎn)生較大影響，消費者處理消息超時亏狰，Kafka集群配置的 max.poll.interval.ms 的值役纹，那么該消費者將會自動離組. 心跳超時，如果消費者在指定的session.timeout.ms時間內(nèi)沒有匯報心跳暇唾，
   那么Kafka就會認為該消費已經(jīng)dead了

24. Kafka 的 副本備份策略是什么促脉？

kafka 采用的是同步和異步共同優(yōu)點的備份策略，即將leader 的所有 follower 進行同步完畢才返回策州，ack. 只不過這個全部的副本是指的是 在 ISR 隊列中的副本瘸味。

ISR 隊列，是指 follower 副本存活且和 zookeeper 保持連接够挂，同時其響應時間 較快旁仿。不滿足條件的會被踢出去，滿足的會被加入孽糖。

HW 高水位枯冈，表明 所有副本都同步到的 offset ，所有分區(qū)的最小offset ,那么 leader 也向 消費者提供的 HW.

LEO 每一個分區(qū)上的最新(大) offset

kafka采取同步和異步的共同優(yōu)點办悟，所以使用ISR的方法霜幼。把Follow中同步慢的節(jié)點從ISR中進行T除，從而保證了復制數(shù)據(jù)的速度誉尖。如果leader副本宕機罪既，那么從ISR中選舉出來新的leader副本。因為follow副本中都有記錄HW铡恕。這樣也會減少數(shù)據(jù)的丟失琢感。Follow副本能夠從leader中批量的讀取數(shù)據(jù)并批量寫入，從而減少了I/0的開銷探熔。

25. kafka 處理請求方案驹针？

kafka 處理請求 類似于 Reactor 模式。

網(wǎng)絡(luò)線程負責接受 請求诀艰， 然后將請求放入共享的請求隊列中柬甥。

broker 有個 IO線程池饮六， 負責從共享隊列中取出請求， 執(zhí)行真正的處理苛蒲， 如果是 produce ,將消息寫入底層磁盤的日志中卤橄， 如果是 fetch ，則從磁盤讀取消息臂外。

當 IO線程 處理完請求窟扑，將生成的響應 發(fā)送到 網(wǎng)絡(luò) 線程池的響應隊列中

請求隊列是所有網(wǎng)絡(luò)線程共享的，而響應隊列是每個網(wǎng)絡(luò)線程專屬的

26. kafka controller 的作用漏健？什么是腦裂怎么解決嚎货？

早期的版本并沒有采用 kafka Controller 對分區(qū)和副本進行管理，而是依賴于 zookeeper蔫浆， 每一個 broker 都會在 zookeeper 上為分區(qū)和副本注冊大量的監(jiān)聽器殖属。這種嚴重依賴于zookeeper 會有腦裂和 羊群效應。

只有kafka 的 controller 監(jiān)控 zookeeper , 其他的 node 再和 controller 通信瓦盛，減少 zookeeper的 壓力忱辅。

什么是腦裂？
kafka中只有一個控制器controller 負責分區(qū)的leader選舉谭溉，同步broker的新增或刪除消息墙懂，但有時由于網(wǎng)絡(luò)問題，可能同時有兩個broker認為自己是controller扮念，這時候其他的broker就會發(fā)生腦裂损搬，不知道該聽從誰的。

如何解決柜与？controller epoch
每當新的controller產(chǎn)生的時候就會在zk中生成一個全新的巧勤、數(shù)值更大的controller epoch的標識，并同步給其他的broker進行保存弄匕，這樣當?shù)诙€controller發(fā)送指令時颅悉，其他的broker就會自動忽略。

27. kafka controller 的競選策略迁匠？

在任意時刻剩瓶，集群中有且僅有一個控制器。

每個broker啟動的時候會去嘗試去讀取zookeeper 中/controller節(jié)點的brokerid的值城丧，如果讀取到brokerid的值不為-1延曙，則表示已經(jīng)有其它broker節(jié)點成功競選為控制器，所以當前broker就會放棄競選亡哄；如果Zookeeper中不存在/controller這個節(jié)點枝缔，或者這個節(jié)點中的數(shù)據(jù)異常，那么就會嘗試去創(chuàng)建/controller這個節(jié)點蚊惯，當前broker去創(chuàng)建節(jié)點的時候愿卸，也有可能其他broker同時去嘗試創(chuàng)建這個節(jié)點灵临，只有創(chuàng)建成功的那個broker才會成為控制器，而創(chuàng)建失敗的broker則表示競選失敗趴荸。每個broker都會在內(nèi)存中保存當前控制器的brokerid值儒溉，這個值可以標識為activeControllerId。

28. 生產(chǎn)者冪等性和事務是什么赊舶？

目的： 進行retry重試時睁搭，只會生成一個消息赶诊。

為了實現(xiàn)Producer的冪等性笼平，Kafka引入了Producer ID（即PID）和Sequence Number。

PID舔痪。每個新的Producer在初始化的時候會被分配一個唯一的PID寓调，這個PID對用戶是不可見的。

Sequence Numbler锄码。（對于每個PID夺英，該Producer發(fā)送數(shù)據(jù)的每個<Topic, Partition>都對應一個從0開始單調(diào)遞增的Sequence Number。不是offset

實現(xiàn)原理： broker 在緩存中保存 序列號滋捶， 對于接受的每一條消息痛悯，如果序列號 比 緩存中的大 1 則接受，否則丟棄重窟。但是者只能保證單個生產(chǎn)者對分區(qū)的 exactly once 語義载萌。

，kafka事務屬性是指一系列的生產(chǎn)者生產(chǎn)消息和消費者提交偏移量的操作在一個事務巡扇，或者說是是一個原子操作）扭仁，同時成功或者失敗。

在事務屬性之前先引入了生產(chǎn)者冪等性厅翔，它的作用為：

生產(chǎn)者多次發(fā)送消息可以封裝成一個原子操作乖坠，要么都成功，要么失敗
consumer-transform-producer模式下刀闷，因為消費者提交偏移量出現(xiàn)問題熊泵，導致在重復消費消息時，生產(chǎn)者重復生產(chǎn)消息甸昏。需要將這個模式下消費者提交偏移量操作和生成者一系列生成消息的操作封裝成一個原子操作戈次。

事務屬性實現(xiàn)前提是冪等性，即在配置事務屬性transaction id時筒扒，必須還得配置冪等性怯邪；但是冪等性是可以獨立使用的，不需要依賴事務屬性花墩。

29. 什么是kafka 消費者組悬秉？

消費者組是 kafka 提供的可以擴展且具有容錯性的消費者機制澄步。 一個分區(qū)，只能被消費者組中的一個消費者進行消費和泌。

當消費者數(shù)量多于分區(qū)數(shù)量時村缸，多于的消費者空閑。

當消費者數(shù)量少于分區(qū)數(shù)量時武氓，一個消費者可能訂閱多個分區(qū)梯皿。

發(fā)揮 consumer 最大的效果就是，consumer 數(shù)和topic 下的 partitions 數(shù)相等县恕。

30. Kafka中是怎么體現(xiàn)消息順序性的东羹？

kafka每個partition中的消息在寫入時都是有序的，消費時忠烛，每個partition只能被每一個group中的一個消費者消費属提，保證了消費時也是有序的。
整個topic不保證有序美尸。如果為了保證topic整個有序冤议，那么將partition調(diào)整為1.

31. Kafka生產(chǎn)者客戶端中使用了幾個線程來處理？分別是什么师坎？

2個阎毅，主線程和Sender線程喘落。主線程負責創(chuàng)建消息，然后通過分區(qū)器、序列化器莲镣、攔截器作用之后緩存到累加器RecordAccumulator中碰纬。Sender線程負責將RecordAccumulator中消息發(fā)送到kafka中.

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

offset+1

33. 有哪些情形會造成重復消費呐萌？

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

34. 有哪些情形會造成重復消費渗磅？

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

35. KafkaConsumer是非線程安全的，那么怎么樣實現(xiàn)多線程消費按灶？

1.在每個線程中新建一個KafkaConsumer

2.單線程創(chuàng)建KafkaConsumer症革，多個處理線程處理消息（難點在于是否要考慮消息順序性，offset的提交方式）

36. 生產(chǎn)者策略?

1. 分區(qū)：默認是 RR 的輪詢分區(qū)劃分規(guī)則鸯旁， 若指定了Key 則將key的hash值 % 分區(qū)號進行分區(qū)

2. kafka數(shù)據(jù)的可靠性： 分區(qū)必須確認收到噪矛，同時副本備份成功。 ack

半數(shù)以上follower完成備份 發(fā)送 ACK, 問題是選舉新的leader ,容忍 n 臺故障铺罢，需要 2n + 1 個副本

全部完成艇挨， 問題是延遲長， Kafka 選擇這種韭赘，但是問題是 存在一個慢 缩滨，或者掛掉，

3. ISR 代表同步副本，leader 從 ISR 中選新 leader, 通信時間 脉漏，在延遲時間內(nèi)去掉

kafka 中維護 ISR 的隊列

當leader 接受到消息后苞冯，通知 ISR 中的follow 完成備份

4. acks 0 收到， 1 leader 完成 -1 leader,follower所有follow完成侧巨，（重復數(shù)據(jù)）

產(chǎn)生同步數(shù)據(jù) 舅锄，follower 備份完成后， 這是leader 掛掉司忱， producer 任務沒收到皇忿，向follewer備份選舉后的重復發(fā)送數(shù)據(jù)

一致性： follower還沒同步完成，同步一半 leader 掛了坦仍，選舉后作為leader 后原leader 活了鳍烁，導致數(shù)據(jù)不一致

消費數(shù)據(jù)一致性：Leo: 每一個分區(qū)副本的最大 offset ，設(shè)置一個 HW 指的是高水位桨踪，所有分區(qū)leo的最小位置,HW之前的數(shù)據(jù)才對消費者可見

存儲數(shù)據(jù)一致性： 重新選leader 給所有分區(qū)發(fā)生消息老翘，直接截取數(shù)據(jù)到HW.

5. exactly-once : ack 為0 at-less-most

冪等性 + 至少一次 為精準一次

使用冪等性芹啥，在kafka 的 broker 消除數(shù)據(jù)的重復锻离， kafka使用冪等性，默認 ack 為-1

首先給每一個生產(chǎn)者 添加一個 id , 給每一個消息 添加一個序列號墓怀， 如果同一個 生產(chǎn)者汽纠， 同一個消息序列號， 發(fā)往同一個分區(qū)傀履，如果已經(jīng)接受過虱朵，就進行去重。

但是生產(chǎn)者掛了重啟钓账，那么它的id 號也就變了碴犬，也就不能保證精準 一致性

37. 消費者策略?

1. 分區(qū) ， RR 輪詢梆暮，將當前消費者組不同的主題服协，當做一個整體，經(jīng)輪詢啦粹。好處偿荷，消費者組里面的消費最多差一個。

保證消費者組里面消費的topic 是一樣的唠椭。 Range 是按照單個主題進行劃分跳纳，將不同的topic 不當做一個整體進行考慮。

觸發(fā)時在消費者組里面消費者個數(shù)變化時會觸發(fā)分區(qū)贪嫂，重新設(shè)置分配分配策略寺庄。

2. offset

消費者組 + 主題 + 分區(qū) 決定 offset, 消費者連接
Kafka 可以順序?qū)懘疟P， 零拷貝技術(shù)

38. Range 分區(qū)?

Range 分區(qū)不會把主題看做一個整體進行劃分

假設(shè) 有兩個主題， T1(0,1,2), T2(0,1,2), 兩個消費者組 （A斗塘，B） (C)

A 消費者 訂閱 T1 , B 訂閱 T1饶深， T2 ，C 訂閱了 T1

RR : 如果采用的RR 發(fā)現(xiàn) A,B 消費者共用同一個組逛拱， 則會把 A,B 訂閱的topic 當做一個整體進行考慮敌厘。

A,B 進行輪詢的分區(qū)有：　T1 0 T1 1 T1 2 T2 0 T2 1 T2 3

Range : 按主題劃分，先考慮誰訂閱了這個主題朽合，然后再進行劃分

39. Kafka 如何保證數(shù)據(jù)的順序性俱两？

kafka：一個topic，一個partition曹步，一個consumer宪彩，內(nèi)部多線程.

kafka寫到一個partition中的數(shù)據(jù)一定是有數(shù)據(jù)的。

解決辦法： 一個topic讲婚，一個partition尿孔，一個consumer，內(nèi)部單線程消費筹麸，寫N個內(nèi)存queue活合，然后N個線程分別消費一個內(nèi)存queue即可，既消費者不要使用多線程進行處理物赶“字福或者你想多線程進行處理，你可以建立一個內(nèi)存隊列酵紫，通過hash進任務id相同分到一個內(nèi)存隊列告嘲，每一個內(nèi)存隊列對應一個線程。

40. 常見MQ 的區(qū)別奖地？

ActiveMQ ：最早大家都用ActiveMQ橄唬，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證参歹，社區(qū)也不是很活躍仰楚，單機吞吐量，萬級泽示，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級缸血，響應為ms級別，有較低的概率丟失數(shù)據(jù)械筛。

RabbitMQ ：單機吞吐率萬級捎泻，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級，但是適合于中小型企業(yè)埋哟，因為自帶了友好的監(jiān)控和維護界面笆豁，社區(qū)相對比較活躍郎汪，幾乎每個月都發(fā)布幾個版本分，在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些闯狱，但是問題也是顯而易見的煞赢，RabbitMQ確實吞吐量會低一些，這是因為他做的實現(xiàn)機制比較重哄孤，同時語言在國內(nèi)很少有人會照筑。

RocketMQ ：單機吞吐量10萬級，RocketMQ也是可以支撐高吞吐的一種MQ瘦陈，topic可以達到幾百凝危，幾千個的級別，吞吐量會有較小幅度的下降晨逝，這是RocketMQ的一大優(yōu)勢蛾默，在同等機器下，可以支撐大量的topic捉貌，可用性非常高支鸡，分布式架構(gòu)，在阿里大規(guī)模應用過趁窃，有阿里品牌保障牧挣，日處理消息上百億之多，可以做到大規(guī)模吞吐棚菊，性能也非常好浸踩，分布式擴展也很方便叔汁，源碼是JAVA.

Kafka : 單機吞吐量10萬級別统求，這是kafka最大的優(yōu)點，就是吞吐量高据块。一般配合大數(shù)據(jù)類的系統(tǒng)來進行實時數(shù)據(jù)計算码邻、日志采集等場景.topic從幾十個到幾百個的時候，吞吐量會大幅度下降
所以在同等機器下另假，kafka盡量保證topic數(shù)量不要過多像屋。如果要支撐大規(guī)模topic，需要增加更多的機器資源,可用性非常高边篮，kafka是分布式的己莺，一個數(shù)據(jù)多個副本，少數(shù)機器宕機戈轿，不會丟失數(shù)據(jù)凌受，不會導致不可用。