1、Kafka是什么？

答：

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

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

• topic：消息類別，Kafka按照topic來分類消息

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

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

• Consumer：消息消費者

• Consumer Group：消費者分組，每個Consumer必須屬于一個group

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

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

答：

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

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

答：

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

4、負載均衡（partition會均衡分布到不同broker上）

答：

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

5、批量發(fā)送

答：

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

6、壓縮（GZIP或Snappy）

答：

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

7、消費者設(shè)計

答：

Kafka架構(gòu)圖

8、Consumer Group

答：

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

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

答：

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

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

答：

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

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

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

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

11、consumer是推還是拉？

答：

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

一些消息系統(tǒng)比如Scribe和Apache Flume采用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由 broker決定消息推送的速率，對于不同消費速率的consumer就不太好處理了。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費消息，但不幸的是，push模式下，當(dāng) broker推送的速率遠大于consumer消費的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統(tǒng)的pull模式。

Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker 拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導(dǎo)致一次只推送較少的消息而造成浪費。Pull模式下，consumer就可以根據(jù)自己的消費能力去決定這些策略。

Pull有個缺點是，如果broker沒有可供消費的消息，將導(dǎo)致consumer不斷在循環(huán)中輪詢，直到新消息到t達。為了避免這點，Kafka有個參數(shù)可以讓consumer阻塞知道新消息到達(當(dāng)然也可以阻塞知道消息的數(shù)量達到某個特定的量這樣就可以批量發(fā)送)。

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

答：

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

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

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

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

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

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

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

13、講一下主從同步。

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

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

答：

1.解耦：

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

2.冗余：

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

3.擴展性：

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。

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

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

5.可恢復(fù)性：

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

6.順序保證：

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

7.緩沖：

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

8.異步通信：

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

15、Zookeeper對于Kafka的作用是什么？

答：

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

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

答：

（1）節(jié)點必須可以維護和ZooKeeper 的連接，Zookeeper通過心跳機制檢查每個節(jié)點的連接

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

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

答：

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

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

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

18、講一講kafka的ack的三種機制

答：

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

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

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

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

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

答：

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

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

答：

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

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

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

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

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

21、如何控制消費的位置？

答：

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

22、kafka分布式（不是單機）的情況下，如何保證消息的順序消費？

答：

Kafka分布式的單位是partition，同一個partition用一個write ahead log組織，所以可以保證FIFO的順序。不同partition之間不能保證順序。但是絕大多數(shù)用戶都可以通過message key來定義，因為同一個key的Message可以保證只發(fā)送到同一個partition。

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

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

23、kafka的高可用機制是什么？

答：

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

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

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

答：

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

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

比如你是寫Redis，那沒問題了，反正每次都是set，天然冪等性。

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

比如基于數(shù)據(jù)庫的唯一鍵來保證重復(fù)數(shù)據(jù)不會重復(fù)插入多條。因為有唯一鍵約束了，重復(fù)數(shù)據(jù)插入只會報錯，不會導(dǎo)致數(shù)據(jù)庫中出現(xiàn)臟數(shù)據(jù)。

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