1、Kafka是什么？

答：

Kafka是一種高吞吐量、分布式、基于發(fā)布/訂閱的消息系統(tǒng)，最初由LinkedIn公司開(kāi)發(fā)，使用Scala語(yǔ)言編寫，目前是Apache的開(kāi)源項(xiàng)目。

• broker： Kafka服務(wù)器，負(fù)責(zé)消息存儲(chǔ)和轉(zhuǎn)發(fā)

• topic：消息類別，Kafka按照topic來(lái)分類消息

• partition： topic的分區(qū)，一個(gè)topic可以包含多個(gè)partition， topic 消息保存在各個(gè)partition上4. offset：消息在日志中的位置，可以理解是消息在partition上的偏移量，也是代表該消息的唯一序號(hào)

• Producer：消息生產(chǎn)者

• Consumer：消息消費(fèi)者

• Consumer Group：消費(fèi)者分組，每個(gè)Consumer必須屬于一個(gè)group

• Zookeeper：保存著集群 broker、 topic、 partition等meta 數(shù)據(jù)；另外，還負(fù)責(zé)broker故障發(fā)現(xiàn)， partition leader選舉，負(fù)載均衡等功能

2、partition的數(shù)據(jù)文件（offffset，MessageSize，data）

答：

partition中的每條Message包含了以下三個(gè)屬性： offset，MessageSize，data，其中offset表示Message在這個(gè)partition中的偏移量，offset不是該Message在partition數(shù)據(jù)文件中的實(shí)際存儲(chǔ)位置，而是邏輯上一個(gè)值，它唯一確定了partition中的一條Message，可以認(rèn)為offset是partition中Message的 id； MessageSize表示消息內(nèi)容data的大小；data為Message的具體內(nèi)容。

3、數(shù)據(jù)文件分段 segment（順序讀寫、分段命令、二分查找）

答：

Kafka為每個(gè)分段后的數(shù)據(jù)文件建立了索引文件，文件名與數(shù)據(jù)文件的名字是一樣的，只是文件擴(kuò)展名為index。 index文件中并沒(méi)有為數(shù)據(jù)文件中的每條Message建立索引，而是采用了稀疏存儲(chǔ)的方式，每隔一定字節(jié)的數(shù)據(jù)建立一條索引。這樣避免了索引文件占用過(guò)多的空間，從而可以將索引文件保留在內(nèi)存中。

4、負(fù)載均衡（partition會(huì)均衡分布到不同broker上）

答：

由于消息topic由多個(gè)partition組成，且partition會(huì)均衡分布到不同broker上。因此，為了有效利用broker集群的性能，提高消息的吞吐量，producer可以通過(guò)隨機(jī)或者h(yuǎn)ash等方式，將消息平均發(fā)送到多個(gè)partition上，以實(shí)現(xiàn)負(fù)載均衡。

5、批量發(fā)送

答：

是提高消息吞吐量重要的方式， Producer端可以在內(nèi)存中合并多條消息后，以一次請(qǐng)求的方式發(fā)送了批量的消息給broker，從而大大減少broker存儲(chǔ)消息的IO操作次數(shù)。但也一定程度上影響了消息的實(shí)時(shí)性，相當(dāng)于以時(shí)延代價(jià)，換取更好的吞吐量。

6、壓縮（GZIP或Snappy）

答：

Producer端可以通過(guò)GZIP或Snappy格式對(duì)消息集合進(jìn)行壓縮。 Producer端進(jìn)行壓縮之后，在Consumer端需進(jìn)行解壓。壓縮的好處就是減少傳輸?shù)臄?shù)據(jù)量，減輕對(duì)網(wǎng)絡(luò)傳輸?shù)膲毫?#xff0c;在對(duì)大數(shù)據(jù)處理上，瓶頸往往體現(xiàn)在網(wǎng)絡(luò)上而不是CPU（壓縮和解壓會(huì)耗掉部分CPU資源）。

7、消費(fèi)者設(shè)計(jì)

答：

Kafka架構(gòu)圖

8、Consumer Group

答：

同一Consumer Group中的多個(gè)Consumer實(shí)例，不同時(shí)消費(fèi)同一個(gè)partition，等效于隊(duì)列模式。 partition內(nèi)消息是有序的， Consumer通過(guò)pull方式消費(fèi)消息。 Kafka不刪除已消費(fèi)的消息對(duì)于partition，順序讀寫磁盤數(shù)據(jù)，以時(shí)間復(fù)雜度O(1)方式提供消息持久化能力。

9、如何獲取topic主題的列表

答：

bin/kafka-topics.sh --list --zookeeper localhost:2181

10、生產(chǎn)者和消費(fèi)者的命令行是什么？

答：

生產(chǎn)者在主題上發(fā)布消息：

bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topic Hello-Kafa

注意這里的 IP 是 server.properties 中的 listeners 的配置。接下來(lái)每個(gè)新行就是輸入一條新消息。
消費(fèi)者接受消息：

bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic Hello-Kafka --from-beginning

11、consumer是推還是拉？

答：

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ā)送)。

12、講講kafka維護(hù)消費(fèi)狀態(tài)跟蹤的方法

答：

大部分消息系統(tǒng)在broker端的維護(hù)消息被消費(fèi)的記錄：

一個(gè)消息被分發(fā)到consumer后broker就馬上進(jìn)行標(biāo)記或者等待customer的通知后進(jìn)行標(biāo)記。這樣也可以在消息在消費(fèi)后立馬就刪除以減少空間占用。

但是這樣會(huì)不會(huì)有什么問(wèn)題呢？如果一條消息發(fā)送出去之后就立即被標(biāo)記為消費(fèi)過(guò)的，一旦consumer處理消息時(shí)失敗了（比如程序崩潰）消息就丟失了。

為了解決這個(gè)問(wèn)題，很多消息系統(tǒng)提供了另外一個(gè)個(gè)功能：當(dāng)消息被發(fā)送出去之后僅僅被標(biāo)記為已發(fā)送狀態(tài)，當(dāng)接到consumer已經(jīng)消費(fèi)成功的通知后才標(biāo)記為已被消費(fèi)的狀態(tài)。

這雖然解決了消息丟失的問(wèn)題，但產(chǎn)生了新問(wèn)題，首先如果consumer處理消息成功了但是向broker發(fā)送響應(yīng)時(shí)失敗了，這條消息將被消費(fèi)兩次。第二個(gè)問(wèn)題時(shí)，broker必須維護(hù)每條消息的狀態(tài)，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來(lái)了，且不說(shuō)要維護(hù)大量的狀態(tài)數(shù)據(jù)，比如如果消息發(fā)送出去但沒(méi)有收到消費(fèi)成功的通知，這條消息將一直處于被鎖定的狀態(tài)，Kafka采用了不同的策略。Topic被分成了若干分區(qū)，每個(gè)分區(qū)在同一時(shí)間只被一個(gè)consumer消費(fèi)。

這意味著每個(gè)分區(qū)被消費(fèi)的消息在日志中的位置僅僅是一個(gè)簡(jiǎn)單的整數(shù)：offset。

這樣就很容易標(biāo)記每個(gè)分區(qū)消費(fèi)狀態(tài)就很容易了，僅僅需要一個(gè)整數(shù)而已。這樣消費(fèi)狀態(tài)的跟蹤就很簡(jiǎn)單了。這帶來(lái)了另外一個(gè)好處：consumer可以把offset調(diào)成一個(gè)較老的值，去重新消費(fèi)老的消息。這對(duì)傳統(tǒng)的消息系統(tǒng)來(lái)說(shuō)看起來(lái)有些不可思議，但確實(shí)是非常有用的，誰(shuí)規(guī)定了一條消息只能被消費(fèi)一次呢？

13、講一下主從同步。

答：
Kafka允許topic的分區(qū)擁有若干副本，這個(gè)數(shù)量是可以配置的，你可以為每個(gè)topci配置副本的數(shù)量。Kafka會(huì)自動(dòng)在每個(gè)個(gè)副本上備份數(shù)據(jù),所以當(dāng)一個(gè)節(jié)點(diǎn)down掉時(shí)數(shù)據(jù)依然是可用的.， Kafka的副本功能不是必須的，你可以配置只有一個(gè)副本，這樣其實(shí)就相當(dāng)于只有一份數(shù)據(jù)。 創(chuàng)建副本的單位是topic的分區(qū),每個(gè)分區(qū)都有一個(gè)leader和零或多個(gè)followers。所有的讀寫操作都由leader處理，一般分區(qū)的數(shù)量都比broker的數(shù)量多的多，各分區(qū)的leader均勻的分布在brokers中。

14、為什么需要消息系統(tǒng)，mysql 不能滿足需求嗎？

答：

1.解耦：

允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過(guò)程，只要確保它們遵守同樣的接口約束。

2.冗余：

消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過(guò)這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。許多消息隊(duì)列所采用的”插入-獲取-刪除”范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

3.擴(kuò)展性：

因?yàn)橄㈥?duì)列解耦了你的處理過(guò)程，所以增大消息入隊(duì)和處理的頻率是很容易的，只要另外增加處理過(guò)程即可。

4.靈活性 & 峰值處理能力：

在訪問(wèn)量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見(jiàn)。如果為以能處理這類峰值訪問(wèn)為標(biāo)準(zhǔn)來(lái)投入資源隨時(shí)待命無(wú)疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住突發(fā)的訪問(wèn)壓力，而不會(huì)因?yàn)橥话l(fā)的超負(fù)荷的請(qǐng)求而完全崩潰。

5.可恢復(fù)性：

系統(tǒng)的一部分組件失效時(shí)，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。

6.順序保證：

在大多使用場(chǎng)景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來(lái)就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來(lái)處理。（Kafka 保證一個(gè) Partition 內(nèi)的消息的有序性）

7.緩沖：

有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過(guò)系統(tǒng)的速度，解決生產(chǎn)消息和消費(fèi)消息的處理速度不一致的情況。

8.異步通信：

很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。

15、Zookeeper對(duì)于Kafka的作用是什么？

答：

Zookeeper是一個(gè)開(kāi)放源碼的、高性能的協(xié)調(diào)服務(wù)，它用于Kafka的分布式應(yīng)用。Zookeeper主要用于在集群中不同節(jié)點(diǎn)之間進(jìn)行通信在Kafka中，它被用于提交偏移量，因此如果節(jié)點(diǎn)在任何情況下都失敗了，它都可以從之前提交的偏移量中獲取除此之外，它還執(zhí)行其他活動(dòng)，如：leader檢測(cè)、分布式同步、配置管理、識(shí)別新節(jié)點(diǎn)何時(shí)離開(kāi)或連接、集群、節(jié)點(diǎn)實(shí)時(shí)狀態(tài)等等。

16、Kafka判斷一個(gè)節(jié)點(diǎn)是否還活著有那兩個(gè)條件？

答：

（1）節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper 的連接，Zookeeper通過(guò)心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接

（2）如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫操作，延時(shí)不能太久

17、Kafka與傳統(tǒng)MQ消息系統(tǒng)之間有三個(gè)關(guān)鍵區(qū)別

答：

(1).Kafka持久化日志，這些日志可以被重復(fù)讀取和無(wú)限期保留

(2).Kafka是一個(gè)分布式系統(tǒng)：它以集群的方式運(yùn)行，可以靈活伸縮，在內(nèi)部通過(guò)復(fù)制數(shù)據(jù)提升容錯(cuò)能力和高可用性

(3).Kafka支持實(shí)時(shí)的流式處理

18、講一講kafka的ack的三種機(jī)制

答：

request.required.acks有三個(gè)值0 1 -1(all)

0:生產(chǎn)者不會(huì)等待broker的ack，這個(gè)延遲最低但是存儲(chǔ)的保證最弱當(dāng)server掛掉的時(shí)候就會(huì)丟數(shù)據(jù)。

1：服務(wù)端會(huì)等待ack值leader副本確認(rèn)接收到消息后發(fā)送ack但是如果leader掛掉后他不確保是否復(fù)制完成新leader也會(huì)導(dǎo)致數(shù)據(jù)丟失。

-1(all)：服務(wù)端會(huì)等所有的follower的副本受到數(shù)據(jù)后才會(huì)受到leader發(fā)出的ack，這樣數(shù)據(jù)不會(huì)丟失。

19、消費(fèi)者如何不自動(dòng)提交偏移量，由應(yīng)用提交？

答：

將auto.commit.offset設(shè)為false，然后在處理一批消息后commitSync() 或者異步提交commitAsync()
即：

20、消費(fèi)者故障，出現(xiàn)活鎖問(wèn)題如何解決？

答：

出現(xiàn) “活鎖 ” 的情況， 是它持續(xù)的發(fā)送心跳， 但是沒(méi)有處理 。為了預(yù)防消費(fèi)者在這種情況 下一 直持有分區(qū)，我們使用max.poll.interval.ms活躍檢測(cè) 機(jī)制 。 在此基礎(chǔ)上，如果你調(diào)用的poll的頻率大于最大間隔，則客戶端將主動(dòng)地離開(kāi)組，以便其 他消費(fèi)者接管該分區(qū)。發(fā)生這種情況時(shí)，你會(huì)看到offset提交失敗（調(diào)用commitSync（）引發(fā)的CommitFailedException）。 這是一種安全機(jī)制，保障只有活動(dòng)成員能夠提交offset。所以要留在組中，你必須持續(xù)調(diào)用poll。

消費(fèi)者提供兩個(gè)配置設(shè)置來(lái)控制poll循環(huán)：

max.poll.interval.ms：增大poll的間隔，可以為消費(fèi)者提供更多的時(shí)間去處理返回的消息（調(diào)用poll(long)返回的消 息，通常返回的消息都是一 批）。缺點(diǎn)是此值越大將會(huì)延遲組重新平衡。

max.poll.records：此設(shè)置限制每次調(diào)用poll返回的消息數(shù)，這樣可以更容易的預(yù)測(cè)每次poll間隔要處理的最大值。通過(guò)調(diào)整此值，可以減少poll間隔，減少重新平衡分組的對(duì)于消息處理時(shí)間不可預(yù)測(cè)地的情況，這些選項(xiàng)是不夠的。

處理這種情況的推薦方法是將消息處理移到另一個(gè)線程中，讓消費(fèi)者繼續(xù)調(diào)用poll。 但是必須注意確保已提交的offset不超過(guò)實(shí)際位置。另外，你必須禁用自動(dòng)提交，并只有在線程完成處理后才為記錄手動(dòng)提交偏移量（取決于你 ）。還要注意 ，你需要pause暫停分區(qū)，不會(huì)從poll接收到新消息，讓線程處理完之前返回的消息（如果你的處理能力比拉取消息的慢，那創(chuàng)建新線 程將導(dǎo)致你機(jī)器內(nèi)存溢出） 。

21、如何控制消費(fèi)的位置？

答：

kafka 使用 seek(TopicPartition, long)指定新的消費(fèi)位置。用于查找服務(wù)器保留的最早和最新的offset的特殊的方法也可用（seekToBeginning(Collection) 和seekToEnd(Collection)）

22、kafka分布式（不是單機(jī)）的情況下，如何保證消息的順序消費(fèi)？

答：

Kafka分布式的單位是partition，同一個(gè)partition用一個(gè)write ahead log組織，所以可以保證FIFO的順序。不同partition之間不能保證順序。但是絕大多數(shù)用戶都可以通過(guò)message key來(lái)定義，因?yàn)橥粋€(gè)key的Message可以保證只發(fā)送到同一個(gè)partition。

Kafka中發(fā)送1條消息的時(shí)候，可以指定(topic, partition, key) 3個(gè)參數(shù)。partiton和key是可選的。如果你指定了partition，那就是所有消息發(fā)往同1個(gè)partition，就是有序的。

并且在消費(fèi)端，Kafka保證，1個(gè)partition只能被1個(gè)consumer消費(fèi)?；蛘吣阒付╧ey（比如order id），具有同1個(gè)key的所有消息，會(huì)發(fā)往同1個(gè)partition。

23、kafka的高可用機(jī)制是什么？

答：

這個(gè)問(wèn)題比較系統(tǒng)，回答出kafka的系統(tǒng)特點(diǎn)，leader和follower的關(guān)系，消息讀寫的順序即可。

24、kafka如何減少數(shù)據(jù)丟失？

25、kafka如何不消費(fèi)重復(fù)數(shù)據(jù)？比如扣款，我們不能重復(fù)的扣？

答：

其實(shí)還是得結(jié)合業(yè)務(wù)來(lái)思考，我這里給幾個(gè)思路：

比如你拿個(gè)數(shù)據(jù)要寫庫(kù)，你先根據(jù)主鍵查一下，如果這數(shù)據(jù)都有了，你就別插入了，update一下好吧。

比如你是寫Redis，那沒(méi)問(wèn)題了，反正每次都是set，天然冪等性。

比如你不是上面兩個(gè)場(chǎng)景，那做的稍微復(fù)雜一點(diǎn)，你需要讓生產(chǎn)者發(fā)送每條數(shù)據(jù)的時(shí)候，里面加一個(gè)全局唯一的id，類似訂單 id之類的東西，然后你這里消費(fèi)到了之后，先根據(jù)這個(gè)id去比如Redis里查一下，之前消費(fèi)過(guò)嗎？如果沒(méi)有消費(fèi)過(guò)，你就處理，然后這個(gè)id寫Redis。如果消費(fèi)過(guò)了，那你就別處理了，保證別重復(fù)處理相同的消息即可。

比如基于數(shù)據(jù)庫(kù)的唯一鍵來(lái)保證重復(fù)數(shù)據(jù)不會(huì)重復(fù)插入多條。因?yàn)橛形ㄒ绘I約束了，重復(fù)數(shù)據(jù)插入只會(huì)報(bào)錯(cuò)，不會(huì)導(dǎo)致數(shù)據(jù)庫(kù)中出現(xiàn)臟數(shù)據(jù)。

總結(jié)
篇幅有限，其他內(nèi)容就不在這里一 一展示了，整理不易，歡迎大家一起交流，喜歡小編分享的文章記得關(guān)注我點(diǎn)贊喲，感謝支持！重要的事情說(shuō)三遍，轉(zhuǎn)發(fā)+轉(zhuǎn)發(fā)+轉(zhuǎn)發(fā)，一定要記得轉(zhuǎn)發(fā)哦！！！