來(lái)源 過(guò)往記憶大數(shù)據(jù)

1茂契、Kafka 都有哪些特點(diǎn)蝶桶？

• 高吞吐量、低延遲：kafka每秒可以處理幾十萬(wàn)條消息掉冶，它的延遲最低只有幾毫秒真竖，每個(gè)topic可以分多個(gè)partition, consumer group 對(duì)partition進(jìn)行consume操作。

• 可擴(kuò)展性：kafka集群支持熱擴(kuò)展

• 持久性厌小、可靠性：消息被持久化到本地磁盤(pán)恢共，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失

• 容錯(cuò)性：允許集群中節(jié)點(diǎn)失敗（若副本數(shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失旇笛恰）

• 高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫(xiě)

2讨韭、請(qǐng)簡(jiǎn)述下你在哪些場(chǎng)景下會(huì)選擇 Kafka？

• 日志收集：一個(gè)公司可以用Kafka可以收集各種服務(wù)的log癣蟋，通過(guò)kafka以統(tǒng)一接口服務(wù)的方式開(kāi)放給各種consumer透硝，例如hadoop、HBase疯搅、Solr等濒生。

• 消息系統(tǒng)：解耦和生產(chǎn)者和消費(fèi)者、緩存消息等幔欧。

• 用戶活動(dòng)跟蹤：Kafka經(jīng)常被用來(lái)記錄web用戶或者app用戶的各種活動(dòng)罪治，如瀏覽網(wǎng)頁(yè)、搜索琐馆、點(diǎn)擊等活動(dòng)规阀，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中，然后訂閱者通過(guò)訂閱這些topic來(lái)做實(shí)時(shí)的監(jiān)控分析瘦麸，或者裝載到hadoop谁撼、數(shù)據(jù)倉(cāng)庫(kù)中做離線分析和挖掘。

• 運(yùn)營(yíng)指標(biāo)：Kafka也經(jīng)常用來(lái)記錄運(yùn)營(yíng)監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)厉碟，生產(chǎn)各種操作的集中反饋喊巍，比如報(bào)警和報(bào)告。

• 流式處理：比如spark streaming和 Flink

3箍鼓、 Kafka 的設(shè)計(jì)架構(gòu)你知道嗎崭参？

簡(jiǎn)單架構(gòu)如下

image

詳細(xì)如下

image

Kafka 架構(gòu)分為以下幾個(gè)部分

• Producer ：消息生產(chǎn)者，就是向 kafka broker 發(fā)消息的客戶端款咖。

• Consumer ：消息消費(fèi)者何暮，向 kafka broker 取消息的客戶端。

• Topic ：可以理解為一個(gè)隊(duì)列铐殃，一個(gè) Topic 又分為一個(gè)或多個(gè)分區(qū)海洼，

• Consumer Group：這是 kafka 用來(lái)實(shí)現(xiàn)一個(gè) topic 消息的廣播（發(fā)給所有的 consumer）和單播（發(fā)給任意一個(gè) consumer）的手段。一個(gè) topic 可以有多個(gè) Consumer Group富腊。

• Broker ：一臺(tái) kafka 服務(wù)器就是一個(gè) broker坏逢。一個(gè)集群由多個(gè) broker 組成。一個(gè) broker 可以容納多個(gè) topic赘被。

• Partition：為了實(shí)現(xiàn)擴(kuò)展性是整，一個(gè)非常大的 topic 可以分布到多個(gè) broker上，每個(gè) partition 是一個(gè)有序的隊(duì)列民假。partition 中的每條消息都會(huì)被分配一個(gè)有序的id（offset）浮入。將消息發(fā)給 consumer，kafka 只保證按一個(gè) partition 中的消息的順序羊异，不保證一個(gè) topic 的整體（多個(gè) partition 間）的順序舵盈。

• Offset：kafka 的存儲(chǔ)文件都是按照 offset.kafka 來(lái)命名，用 offset 做名字的好處是方便查找球化。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可瓦糟。當(dāng)然 the first offset 就是 00000000000.kafka筒愚。

4、Kafka 分區(qū)的目的菩浙？

分區(qū)對(duì)于 Kafka 集群的好處是：實(shí)現(xiàn)負(fù)載均衡巢掺。分區(qū)對(duì)于消費(fèi)者來(lái)說(shuō)，可以提高并發(fā)度劲蜻，提高效率陆淀。

5、你知道 Kafka 是如何做到消息的有序性先嬉？

kafka 中的每個(gè) partition 中的消息在寫(xiě)入時(shí)都是有序的轧苫，而且單獨(dú)一個(gè) partition 只能由一個(gè)消費(fèi)者去消費(fèi)，可以在里面保證消息的順序性疫蔓。但是分區(qū)之間的消息是不保證有序的含懊。

6身冬、Kafka 的高可靠性是怎么實(shí)現(xiàn)的？

可以參見(jiàn)我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

7岔乔、請(qǐng)談一談 Kafka 數(shù)據(jù)一致性原理一致性就是說(shuō)不論是老的 Leader 還是新選舉的 Leader酥筝，Consumer 都能讀到一樣的數(shù)據(jù)。

image

假設(shè)分區(qū)的副本為3雏门，其中副本0是 Leader嘿歌，副本1和副本2是 follower，并且在 ISR 列表里面茁影。雖然副本0已經(jīng)寫(xiě)入了 Message4宙帝，但是 Consumer 只能讀取到 Message2。因?yàn)樗械?ISR 都同步了 Message2呼胚，只有 High Water Mark 以上的消息才支持 Consumer 讀取茄唐，而 High Water Mark 取決于 ISR 列表里面偏移量最小的分區(qū)，對(duì)應(yīng)于上圖的副本2蝇更，這個(gè)很類(lèi)似于木桶原理沪编。

這樣做的原因是還沒(méi)有被足夠多副本復(fù)制的消息被認(rèn)為是“不安全”的，如果 Leader 發(fā)生崩潰年扩，另一個(gè)副本成為新 Leader蚁廓，那么這些消息很可能丟失了。如果我們?cè)试S消費(fèi)者讀取這些消息厨幻，可能就會(huì)破壞一致性相嵌。試想，一個(gè)消費(fèi)者從當(dāng)前 Leader（副本0） 讀取并處理了 Message4况脆，這個(gè)時(shí)候 Leader 掛掉了饭宾，選舉了副本1為新的 Leader，這時(shí)候另一個(gè)消費(fèi)者再去從新的 Leader 讀取消息格了，發(fā)現(xiàn)這個(gè)消息其實(shí)并不存在看铆，這就導(dǎo)致了數(shù)據(jù)不一致性問(wèn)題。

當(dāng)然盛末，引入了 High Water Mark 機(jī)制弹惦，會(huì)導(dǎo)致 Broker 間的消息復(fù)制因?yàn)槟承┰蜃兟敲聪⒌竭_(dá)消費(fèi)者的時(shí)間也會(huì)隨之變長(zhǎng)（因?yàn)槲覀儠?huì)先等待消息復(fù)制完畢）悄但。延遲時(shí)間可以通過(guò)參數(shù) replica.lag.time.max.ms 參數(shù)配置棠隐，它指定了副本在復(fù)制消息時(shí)可被允許的最大延遲時(shí)間。

8檐嚣、ISR助泽、OSR、AR 是什么？

ISR：In-Sync Replicas 副本同步隊(duì)列

OSR：Out-of-Sync Replicas

AR：Assigned Replicas 所有副本

ISR是由leader維護(hù)报咳，follower從leader同步數(shù)據(jù)有一些延遲（具體可以參見(jiàn) 圖文了解 Kafka 的副本復(fù)制機(jī)制）侠讯，超過(guò)相應(yīng)的閾值會(huì)把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas ）列表，新加入的follower也會(huì)先存放在OSR中暑刃。AR=ISR+OSR厢漩。

9、LEO岩臣、HW溜嗜、LSO、LW等分別代表什么

• LEO：是 LogEndOffset 的簡(jiǎn)稱(chēng)架谎，代表當(dāng)前日志文件中下一條

• HW：水位或水诱ㄏ（watermark）一詞，也可稱(chēng)為高水位(high watermark)谷扣，通常被用在流式處理領(lǐng)域（比如Apache Flink土全、Apache Spark等），以表征元素或事件在基于時(shí)間層面上的進(jìn)度会涎。在Kafka中裹匙，水位的概念反而與時(shí)間無(wú)關(guān)，而是與位置信息相關(guān)末秃。嚴(yán)格來(lái)說(shuō)概页，它表示的就是位置信息，即位移（offset）练慕。取 partition 對(duì)應(yīng)的 ISR中 最小的 LEO 作為 HW惰匙，consumer 最多只能消費(fèi)到 HW 所在的位置上一條信息。

• LSO：是 LastStableOffset 的簡(jiǎn)稱(chēng)铃将，對(duì)未完成的事務(wù)而言项鬼，LSO 的值等于事務(wù)中第一條消息的位置(firstUnstableOffset)，對(duì)已完成的事務(wù)而言劲阎，它的值同 HW 相同

• LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值秃臣。

10、Kafka 在什么情況下會(huì)出現(xiàn)消息丟失哪工？可以參見(jiàn)我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

11、怎么盡可能保證 Kafka 的可靠性 可以參見(jiàn)我這篇文章：Kafka 是如何保證數(shù)據(jù)可靠性和一致性

12弧哎、消費(fèi)者和消費(fèi)者組有什么關(guān)系雁比？

image

13撤嫩、Kafka 的每個(gè)分區(qū)只能被一個(gè)消費(fèi)者線程偎捎，如何做到多個(gè)線程同時(shí)消費(fèi)一個(gè)分區(qū)？

參見(jiàn)我這篇文章：Airbnb 是如何通過(guò) balanced Kafka reader 來(lái)擴(kuò)展 Spark streaming 實(shí)時(shí)流處理能力的

14、數(shù)據(jù)傳輸?shù)氖聞?wù)有幾種茴她？

數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：

（1）最多一次: 消息不會(huì)被重復(fù)發(fā)送寻拂，最多被傳輸一次，但也有可能一次不傳輸

（2）最少一次: 消息不會(huì)被漏發(fā)送丈牢，最少被傳輸一次祭钉，但也有可能被重復(fù)傳輸.

（3）精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被

15、Kafka 消費(fèi)者是否可以消費(fèi)指定分區(qū)消息己沛？

Kafa consumer消費(fèi)消息時(shí)慌核，向broker發(fā)出fetch請(qǐng)求去消費(fèi)特定分區(qū)的消息，consumer指定消息在日志中的偏移量（offset）申尼，就可以消費(fèi)從這個(gè)位置開(kāi)始的消息垮卓，customer擁有了offset的控制權(quán)，可以向后回滾去重新消費(fèi)之前的消息师幕，這是很有意義的

16粟按、Kafka消息是采用Pull模式，還是Push模式霹粥？

Kafka最初考慮的問(wèn)題是灭将，customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push蒙挑。在這方面宗侦，Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計(jì)：producer將消息推送到broker，consumer從broker拉取消息忆蚀。

一些消息系統(tǒng)比如Scribe和Apache Flume采用了push模式矾利，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率馋袜，對(duì)于不同消費(fèi)速率的consumer就不太好處理了男旗。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費(fèi)消息，但不幸的是欣鳖，push模式下察皇，當(dāng)broker推送的速率遠(yuǎn)大于consumer消費(fèi)的速率時(shí)，consumer恐怕就要崩潰了泽台。最終Kafka還是選取了傳統(tǒng)的pull模式什荣。Pull模式的另外一個(gè)好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送怀酷。如果為了避免consumer崩潰而采用較低的推送速率稻爬，將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull模式下蜕依，consumer就可以根據(jù)自己的消費(fèi)能力去決定這些策略桅锄。Pull有個(gè)缺點(diǎn)是琉雳，如果broker沒(méi)有可供消費(fèi)的消息，將導(dǎo)致consumer不斷在循環(huán)中輪詢友瘤，直到新消息到t達(dá)翠肘。為了避免這點(diǎn)，Kafka有個(gè)參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)

17辫秧、Kafka 消息格式的演變清楚嗎束倍？Kafka 的消息格式經(jīng)過(guò)了四次大變化，具體可以參見(jiàn)我這篇文章：Apache Kafka消息格式的演變(0.7.x~0.10.x)茶没。

18肌幽、Kafka 偏移量的演變清楚嗎？

參見(jiàn)我這篇文章：圖解Apache Kafka消息偏移量的演變(0.7.x~0.10.x)

19抓半、Kafka 高效文件存儲(chǔ)設(shè)計(jì)特點(diǎn)

• Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段喂急，通過(guò)多個(gè)小文件段，就容易定期清除或刪除已經(jīng)消費(fèi)完文件笛求，減少磁盤(pán)占用廊移。

• 通過(guò)索引信息可以快速定位message和確定response的最大大小。

• 通過(guò)index元數(shù)據(jù)全部映射到memory探入，可以避免segment file的IO磁盤(pán)操作狡孔。

• 通過(guò)索引文件稀疏存儲(chǔ)，可以大幅降低index文件元數(shù)據(jù)占用空間大小

20蜂嗽、Kafka創(chuàng)建Topic時(shí)如何將分區(qū)放置到不同的Broker中

• 副本因子不能大于 Broker 的個(gè)數(shù)苗膝；

• 第一個(gè)分區(qū)（編號(hào)為0）的第一個(gè)副本放置位置是隨機(jī)從 brokerList 選擇的；

• 其他分區(qū)的第一個(gè)副本放置位置相對(duì)于第0個(gè)分區(qū)依次往后移植旧。也就是如果我們有5個(gè) Broker辱揭，5個(gè)分區(qū)，假設(shè)第一個(gè)分區(qū)放在第四個(gè) Broker 上病附，那么第二個(gè)分區(qū)將會(huì)放在第五個(gè) Broker 上问窃；第三個(gè)分區(qū)將會(huì)放在第一個(gè) Broker 上；第四個(gè)分區(qū)將會(huì)放在第二個(gè) Broker 上完沪，依次類(lèi)推域庇；

• 剩余的副本相對(duì)于第一個(gè)副本放置位置其實(shí)是由 nextReplicaShift 決定的，而這個(gè)數(shù)也是隨機(jī)產(chǎn)生的

具體可以參見(jiàn) Kafka創(chuàng)建Topic時(shí)如何將分區(qū)放置到不同的Broker中覆积。

21听皿、Kafka新建的分區(qū)會(huì)在哪個(gè)目錄下創(chuàng)建

在啟動(dòng) Kafka 集群之前，我們需要配置好 log.dirs 參數(shù)宽档，其值是 Kafka 數(shù)據(jù)的存放目錄写穴，這個(gè)參數(shù)可以配置多個(gè)目錄，目錄之間使用逗號(hào)分隔雌贱，通常這些目錄是分布在不同的磁盤(pán)上用于提高讀寫(xiě)性能啊送。

當(dāng)然我們也可以配置 log.dir 參數(shù)，含義一樣欣孤。只需要設(shè)置其中一個(gè)即可馋没。

如果 log.dirs 參數(shù)只配置了一個(gè)目錄，那么分配到各個(gè) Broker 上的分區(qū)肯定只能在這個(gè)目錄下創(chuàng)建文件夾用于存放數(shù)據(jù)降传。

但是如果 log.dirs 參數(shù)配置了多個(gè)目錄篷朵，那么 Kafka 會(huì)在哪個(gè)文件夾中創(chuàng)建分區(qū)目錄呢？答案是：Kafka 會(huì)在含有分區(qū)目錄最少的文件夾中創(chuàng)建新的分區(qū)目錄婆排，分區(qū)目錄名為 Topic名+分區(qū)ID声旺。注意，是分區(qū)文件夾總數(shù)最少的目錄段只，而不是磁盤(pán)使用量最少的目錄腮猖！也就是說(shuō)，如果你給 log.dirs 參數(shù)新增了一個(gè)新的磁盤(pán)赞枕，新的分區(qū)目錄肯定是先在這個(gè)新的磁盤(pán)上創(chuàng)建直到這個(gè)新的磁盤(pán)目錄擁有的分區(qū)目錄不是最少為止澈缺。具體可以參見(jiàn)我博客：https://www.iteblog.com/archives/2231.html

22、談一談 Kafka 的再均衡

在Kafka中炕婶，當(dāng)有新消費(fèi)者加入或者訂閱的topic數(shù)發(fā)生變化時(shí)姐赡，會(huì)觸發(fā)Rebalance(再均衡：在同一個(gè)消費(fèi)者組當(dāng)中，分區(qū)的所有權(quán)從一個(gè)消費(fèi)者轉(zhuǎn)移到另外一個(gè)消費(fèi)者)機(jī)制柠掂，Rebalance顧名思義就是重新均衡消費(fèi)者消費(fèi)项滑。Rebalance的過(guò)程如下：

第一步：所有成員都向coordinator發(fā)送請(qǐng)求，請(qǐng)求入組涯贞。一旦所有成員都發(fā)送了請(qǐng)求枪狂，coordinator會(huì)從中選擇一個(gè)consumer擔(dān)任leader的角色，并把組成員信息以及訂閱信息發(fā)給leader肩狂。第二步：leader開(kāi)始分配消費(fèi)方案摘完，指明具體哪個(gè)consumer負(fù)責(zé)消費(fèi)哪些topic的哪些partition。一旦完成分配傻谁，leader會(huì)將這個(gè)方案發(fā)給coordinator孝治。coordinator接收到分配方案之后會(huì)把方案發(fā)給各個(gè)consumer，這樣組內(nèi)的所有成員就都知道自己應(yīng)該消費(fèi)哪些分區(qū)了审磁。所以對(duì)于Rebalance來(lái)說(shuō)谈飒，Coordinator起著至關(guān)重要的作用

23、談?wù)?Kafka 分區(qū)分配策略

參見(jiàn)我這篇文章 Kafka分區(qū)分配策略(Partition Assignment Strategy)

24态蒂、Kafka Producer 是如何動(dòng)態(tài)感知主題分區(qū)數(shù)變化的杭措？

參見(jiàn)我這篇文章：Kafka Producer是如何動(dòng)態(tài)感知Topic分區(qū)數(shù)變化

25、 Kafka 是如何實(shí)現(xiàn)高吞吐率的钾恢？

Kafka是分布式消息系統(tǒng)手素，需要處理海量的消息鸳址，Kafka的設(shè)計(jì)是把所有的消息都寫(xiě)入速度低容量大的硬盤(pán)，以此來(lái)?yè)Q取更強(qiáng)的存儲(chǔ)能力泉懦，但實(shí)際上稿黍，使用硬盤(pán)并沒(méi)有帶來(lái)過(guò)多的性能損失。kafka主要使用了以下幾個(gè)方式實(shí)現(xiàn)了超高的吞吐率：

• 順序讀寫(xiě)崩哩；

• 零拷貝

• 文件分段

• 批量發(fā)送

• 數(shù)據(jù)壓縮巡球。

具體參見(jiàn)：Kafka是如何實(shí)現(xiàn)高吞吐率的

26、Kafka 監(jiān)控都有哪些邓嘹？

參見(jiàn)我另外幾篇文章：Apache Kafka監(jiān)控之KafkaOffsetMonitor雅虎開(kāi)源的Kafka集群管理器(Kafka Manager)Apache Kafka監(jiān)控之Kafka Web Console還有 JMX

27酣栈、如何為Kafka集群選擇合適的Topics/Partitions數(shù)量

參見(jiàn)我另外幾篇文章：如何為Kafka集群選擇合適的Topics/Partitions數(shù)量

28、談?wù)勀銓?duì) Kafka 事務(wù)的了解汹押？

參見(jiàn)這篇文章：http://www.jasongj.com/kafka/transaction/

29矿筝、談?wù)勀銓?duì) Kafka 冪等的了解？

參見(jiàn)這篇文章：http://www.reibang.com/p/b1599f46229b

30鲸阻、Kafka 缺點(diǎn)跋涣？

• 由于是批量發(fā)送，數(shù)據(jù)并非真正的實(shí)時(shí)鸟悴；

• 對(duì)于mqtt協(xié)議不支持陈辱；

• 不支持物聯(lián)網(wǎng)傳感數(shù)據(jù)直接接入；

• 僅支持統(tǒng)一分區(qū)內(nèi)消息有序细诸，無(wú)法實(shí)現(xiàn)全局消息有序沛贪；

• 監(jiān)控不完善，需要安裝插件震贵；

• 依賴(lài)zookeeper進(jìn)行元數(shù)據(jù)管理利赋；

31、Kafka 新舊消費(fèi)者的區(qū)別

舊的 Kafka 消費(fèi)者 API 主要包括：SimpleConsumer（簡(jiǎn)單消費(fèi)者） 和 ZookeeperConsumerConnectir（高級(jí)消費(fèi)者）猩系。SimpleConsumer 名字看起來(lái)是簡(jiǎn)單消費(fèi)者媚送，但是其實(shí)用起來(lái)很不簡(jiǎn)單，可以使用它從特定的分區(qū)和偏移量開(kāi)始讀取消息寇甸。高級(jí)消費(fèi)者和現(xiàn)在新的消費(fèi)者有點(diǎn)像塘偎，有消費(fèi)者群組，有分區(qū)再均衡拿霉，不過(guò)它使用 ZK 來(lái)管理消費(fèi)者群組吟秩，并不具備偏移量和再均衡的可操控性。

現(xiàn)在的消費(fèi)者同時(shí)支持以上兩種行為绽淘，所以為啥還用舊消費(fèi)者 API 呢涵防？

image

32、Kafka 分區(qū)數(shù)可以增加或減少嗎沪铭？為什么壮池？

我們可以使用 bin/kafka-topics.sh 命令對(duì) Kafka 增加 Kafka 的分區(qū)數(shù)據(jù)偏瓤，但是 Kafka 不支持減少分區(qū)數(shù)。 Kafka 分區(qū)數(shù)據(jù)不支持減少是由很多原因的椰憋，比如減少的分區(qū)其數(shù)據(jù)放到哪里去硼补？是刪除，還是保留熏矿？刪除的話，那么這些沒(méi)消費(fèi)的消息不就丟了离钝。如果保留這些消息如何放到其他分區(qū)里面票编？追加到其他分區(qū)后面的話那么就破壞了 Kafka 單個(gè)分區(qū)的有序性。如果要保證刪除分區(qū)數(shù)據(jù)插入到其他分區(qū)保證有序性卵渴，那么實(shí)現(xiàn)起來(lái)邏輯就會(huì)非常復(fù)雜慧域。

本文參考

https://blog.csdn.net/linke1183982890/article/details/83303003

https://www.cnblogs.com/FG123/p/10095125.html

https://www.cnblogs.com/chenmingjun/p/10480793.html