Kafka知識點整理

1板丽、概述

Kafka起初是由LinkedIn公司采用Scala語言開發(fā)的一個多分區(qū)、多副本且基于Zookeeper協(xié)調(diào)的分布式消息系統(tǒng)壶硅,現(xiàn)已捐獻給Apache基金會葬荷。目前Kafka已經(jīng)被定為為一個分布式流式處理平臺,它以高吞吐岖寞、可持久化抡四、可水平拓展、支持流數(shù)據(jù)處理等多種特性而被廣泛使用仗谆。

消息中間件的作用指巡,核心作用應(yīng)該是解耦、削峰隶垮、異步通信藻雪,對比起直接存入數(shù)據(jù)等方案則有性能上的優(yōu)勢

  • 解耦

  • 冗余(存儲)

  • 擴展性

  • 削峰

  • 可恢復(fù)性

  • 順序保證

  • 緩沖

  • 異步通信

Kafka和各種Mq軟件的比較,有點老了狸吞,RocketMQ有管理后臺

image.jpeg

2阔涉、安裝

參考資料:http://www.cnblogs.com/2YSP/p/8719354.html

在本機下載好了安裝包并編譯后,啟動指令如下

bin/zkServer.sh start

bin/kafka-server-start.sh config/server.properties

3捷绒、服務(wù)集成

    spring cloud集成kafka有兩種方式,如果沒有利用到spring bus和其他模塊比如spring config配合更新緩存的功能贯要,兩種方式基本沒有區(qū)別

一種是直接用spring boot集成 https://blog.csdn.net/olinbsoft/article/details/85645221

另一種是基于spring cloud bus消息總線集成 http://www.iyujian.me/java/spring-cloud-starter-bus-kafka-send-receive.html

    由于kafka同一條信息暖侨,一個group id一般只能消費一次。如果想要廣播崇渗,spring集成kafka時要動態(tài)設(shè)置groupId字逗,可以使用隨機數(shù)的方式來配置spring.kafka.consumer.groupId字段,比如star_ad_${random.uuid}

4宅广、基本概念及機制

  • Producer:生產(chǎn)者葫掉,也就是發(fā)送消息的一方。生產(chǎn)者負責創(chuàng)建消息跟狱,然后將其發(fā)送到 Kafka俭厚。

  • Consumer:消費者,也就是接受消息的一方驶臊。消費者連接到 Kafka 上并接收消息挪挤,進而進行相應(yīng)的業(yè)務(wù)邏輯處理叼丑。

  • Consumer Group:一個消費者組可以包含一個或多個消費者。使用多分區(qū) + 多消費者方式可以極大提高數(shù)據(jù)下游的處理速度扛门,同一消費組中的消費者不會重復(fù)消費消息鸠信,同樣的,不同消費組中的消費者消息消息時互不影響论寨。Kafka 就是通過消費組的方式來實現(xiàn)消息 P2P 模式和廣播模式星立。

  • Broker:服務(wù)代理節(jié)點。Broker 是 Kafka 的服務(wù)節(jié)點葬凳,即 Kafka 的服務(wù)器绰垂。

  • Topic:Kafka 中的消息以 Topic 為單位進行劃分,生產(chǎn)者將消息發(fā)送到特定的 Topic沮明,而消費者負責訂閱 Topic 的消息并進行消費辕坝。

  • Partition:Topic 是一個邏輯的概念,它可以細分為多個分區(qū)荐健,每個分區(qū)只屬于單個主題酱畅。同一個主題下不同分區(qū)包含的消息是不同的,分區(qū)在存儲層面可以看作一個可追加的日志(Log)文件江场,消息在被追加到分區(qū)日志文件的時候都會分配一個特定的偏移量(offset)纺酸。

  • Offset:offset 是消息在分區(qū)中的唯一標識,Kafka 通過它來保證消息在分區(qū)內(nèi)的順序性址否,不過 offset 并不跨越分區(qū)餐蔬,也就是說,Kafka 保證的是分區(qū)有序性而不是主題有序性佑附。

  • Replication:副本樊诺,是 Kafka 保證數(shù)據(jù)高可用的方式,Kafka 同一 Partition 的數(shù)據(jù)可以在多 Broker 上存在多個副本音同,通常只有主副本對外提供讀寫服務(wù)词爬,當主副本所在 broker 崩潰或發(fā)生網(wǎng)絡(luò)一場,Kafka 會在 Controller 的管理下會重新選擇新的 Leader 副本對外提供讀寫服務(wù)权均。默認只有一個副本

  • Record: 實際寫入 Kafka 中并可以被讀取的消息記錄顿膨。每個 record 包含了 key、value 和 timestamp叽赊。

Kafka 將 Topic 進行分區(qū)恋沃,多個分區(qū)可以并發(fā)讀寫。

image.jpeg

通過Offset記錄不同消費者組消費到的最新信息必指,Offset是信息在單個分區(qū)里的唯一標識

image.png

Kafka通過Zookeeper管理多個Boker并保障服務(wù)的高可用

image.png
  • Broker 注冊:Broker 是分布式部署并且之間相互獨立囊咏,Zookeeper 用來管理注冊到集群的所有 Broker 節(jié)點。

  • Topic 注冊: 在 Kafka 中,同一個 Topic 的消息會被分成多個分區(qū)并將其分布在多個 Broker 上匆笤,這些分區(qū)信息及與 Broker 的對應(yīng)關(guān)系也都是由 Zookeeper 在維護

  • 生產(chǎn)者負載均衡:由于同一個 Topic 消息會被分區(qū)并將其分布在多個 Broker 上研侣,因此,生產(chǎn)者需要將消息合理地發(fā)送到這些分布式的 Broker 上炮捧。

  • 消費者負載均衡:與生產(chǎn)者類似庶诡,Kafka 中的消費者同樣需要進行負載均衡來實現(xiàn)多個消費者合理地從對應(yīng)的 Broker 服務(wù)器上接收消息,每個消費者分組包含若干消費者咆课,每條消息都只會發(fā)送給分組中的一個消費者末誓,不同的消費者分組消費自己特定的 Topic 下面的消息,互不干擾书蚪。

Kafka的消息保留機制

Kafka的消息保留有兩個主要機制

  • 消息最長保留特定時間喇澡,默認是168小時也就是一周,超出這個時間的消息會被刪除殊校。

  • 最大容量晴玖,可以設(shè)置主題的每個分區(qū)容量,比如某個主題分區(qū)最大容量是1GB为流。主題總?cè)萘烤褪欠謪^(qū)數(shù)乘以分區(qū)最大容量呕屎,如果總大小超了,最早的消息就會被刪除敬察。

Kafka的消息有序性

   每個分區(qū)中的消息是保證有序的秀睛,但是不同分區(qū)無法保證。Kafka提供了自定義分區(qū)策略莲祸,我們可以通過自定義分區(qū)將特定的消息發(fā)送到一個分區(qū)保障順序蹂安。

5、Kafka的使用

Kafka 的命令行工具在 Kafka 包的/bin目錄下锐帜,主要包括服務(wù)和集群管理腳本田盈,配置腳本,信息查看腳本缴阎,Topic 腳本缠黍,客戶端腳本等。

  • kafka-configs.sh: 配置管理腳本

  • kafka-console-consumer.sh: kafka 消費者控制臺

  • kafka-console-producer.sh: kafka 生產(chǎn)者控制臺

  • kafka-consumer-groups.sh: kafka 消費者組相關(guān)信息

  • kafka-delete-records.sh: 刪除低水位的日志文件

  • kafka-log-dirs.sh:kafka 消息日志目錄信息

  • kafka-mirror-maker.sh: 不同數(shù)據(jù)中心 kafka 集群復(fù)制工具

  • kafka-preferred-replica-election.sh: 觸發(fā) preferred replica 選舉

  • kafka-producer-perf-test.sh:kafka 生產(chǎn)者性能測試腳本

  • kafka-reassign-partitions.sh: 分區(qū)重分配腳本

  • kafka-replica-verification.sh: 復(fù)制進度驗證腳本

  • kafka-server-start.sh: 啟動 kafka 服務(wù)

  • kafka-server-stop.sh: 停止 kafka 服務(wù)

  • kafka-topics.sh:topic 管理腳本

  • kafka-verifiable-consumer.sh: 可檢驗的 kafka 消費者

  • kafka-verifiable-producer.sh: 可檢驗的 kafka 生產(chǎn)者

  • zookeeper-server-start.sh: 啟動 zk 服務(wù)

  • zookeeper-server-stop.sh: 停止 zk 服務(wù)

  • zookeeper-shell.sh:zk 客戶端

通常使用kafka-console-consumer.shkafka-console-producer.sh腳本來測試 Kafka 生產(chǎn)和消費药蜻,kafka-consumer-groups.sh可以查看和管理集群中的 Topic,kafka-topics.sh通常用于查看 Kafka 的消費組情況替饿。

6语泽、Kafka 生產(chǎn)者重要機制

Kafka producer 的正常生產(chǎn)邏輯包含以下幾個步驟:

  1. 配置生產(chǎn)者客戶端參數(shù)創(chuàng)建生產(chǎn)者實例。

  2. 構(gòu)建待發(fā)送的消息视卢。

  3. 發(fā)送消息踱卵。

  4. 關(guān)閉生產(chǎn)者實例。

Producer 發(fā)送消息的過程如下圖所示,需要經(jīng)過攔截器惋砂,序列化器和分區(qū)器妒挎,最終由累加器批量發(fā)送至 Broker。

image.png

Kafka Producer 需要以下必要參數(shù):

  • bootstrap.server: 指定 Kafka 的 Broker 的地址

  • key.serializer: key 序列化器

  • value.serializer: value 序列化器

常見參數(shù):

  • batch.num.messages

    默認值:200西饵,每次批量消息的數(shù)量酝掩,只對 asyc 起作用。

  • request.required.acks

    默認值:0眷柔,0 表示 producer 毋須等待 leader 的確認期虾,1 代表需要 leader 確認寫入它的本地 log 并立即確認,-1 代表所有的備份都完成后確認驯嘱。 只對 async 模式起作用镶苞,這個參數(shù)的調(diào)整是數(shù)據(jù)不丟失和發(fā)送效率的 tradeoff,如果對數(shù)據(jù)丟失不敏感而在乎效率的場景可以考慮設(shè)置為 0鞠评,這樣可以大大提高 producer 發(fā)送數(shù)據(jù)的效率茂蚓。

  • request.timeout.ms

    默認值:10000,確認超時時間剃幌。

  • partitioner.class

    默認值:kafka.producer.DefaultPartitioner聋涨,必須實現(xiàn) kafka.producer.Partitioner,根據(jù) Key 提供一個分區(qū)策略锥忿。有時候我們需要相同類型的消息必須順序處理牛郑,這樣我們就必須自定義分配策略,從而將相同類型的數(shù)據(jù)分配到同一個分區(qū)中敬鬓。

  • producer.type

    默認值:sync淹朋,指定消息發(fā)送是同步還是異步。異步 asyc 成批發(fā)送用 kafka.producer.AyncProducer钉答, 同步 sync 用 kafka.producer.SyncProducer础芍。同步和異步發(fā)送也會影響消息生產(chǎn)的效率。

  • compression.topic

    默認值:none数尿,消息壓縮仑性,默認不壓縮。其余壓縮方式還有右蹦,"gzip"诊杆、"snappy"和"lz4"。對消息的壓縮可以極大地減少網(wǎng)絡(luò)傳輸量何陆、降低網(wǎng)絡(luò) IO晨汹,從而提高整體性能。

  • compressed.topics

    默認值:null贷盲,在設(shè)置了壓縮的情況下淘这,可以指定特定的 topic 壓縮,未指定則全部壓縮。

  • message.send.max.retries

    默認值:3铝穷,消息發(fā)送最大嘗試次數(shù)钠怯。

  • retry.backoff.ms

    默認值:300,每次嘗試增加的額外的間隔時間曙聂。

  • topic.metadata.refresh.interval.ms

    默認值:600000晦炊,定期的獲取元數(shù)據(jù)的時間。當分區(qū)丟失筹陵,leader 不可用時 producer 也會主動獲取元數(shù)據(jù)刽锤,如果為 0,則每次發(fā)送完消息就獲取元數(shù)據(jù)朦佩,不推薦并思。如果為負值,則只有在失敗的情況下獲取元數(shù)據(jù)语稠。

  • queue.buffering.max.ms

    默認值:5000宋彼,在 producer queue 的緩存的數(shù)據(jù)最大時間,僅僅 for asyc仙畦。

  • queue.buffering.max.message

    默認值:10000输涕,producer 緩存的消息的最大數(shù)量,僅僅 for asyc慨畸。

  • queue.enqueue.timeout.ms

    默認值:-1莱坎,0 當 queue 滿時丟掉,負值是 queue 滿時 block, 正值是 queue 滿時 block 相應(yīng)的時間寸士,僅僅 for asyc檐什。

7、Kafka消費者機制

Kafka 有消費組的概念弱卡,每個消費者只能消費所分配到的分區(qū)的消息乃正,每一個分區(qū)只能被一個消費組中的一個消費者所消費,所以同一個消費組中消費者的數(shù)量如果超過了分區(qū)的數(shù)量婶博,將會出現(xiàn)有些消費者分配不到消費的分區(qū)瓮具。消費組與消費者關(guān)系如下圖所示:

image.jpeg

Kafka Consumer Client 消費消息通常包含以下步驟:

  1. 配置客戶端,創(chuàng)建消費者

  2. 訂閱主題

  3. 拉去消息并消費

  4. 提交消費位移

  5. 關(guān)閉消費者實例

image.png

因為 Kafka 的 Consumer 客戶端是線程不安全的凡人,為了保證線程安全名党,并提升消費性能,可以在 Consumer 端采用類似 Reactor 的線程模型來消費數(shù)據(jù)挠轴。

image.png

消費者常用參數(shù)

  • bootstrap.servers: 連接 broker 地址兑巾,host:port 格式。

  • group.id: 消費者隸屬的消費組忠荞。

  • key.deserializer: 與生產(chǎn)者的key.serializer對應(yīng),key 的反序列化方式。

  • value.deserializer: 與生產(chǎn)者的value.serializer對應(yīng)委煤,value 的反序列化方式堂油。

  • session.timeout.ms: coordinator 檢測失敗的時間。默認 10s 該參數(shù)是 Consumer Group 主動檢測 (組內(nèi)成員 comsummer) 崩潰的時間間隔碧绞,類似于心跳過期時間府框。

  • auto.offset.reset: 該屬性指定了消費者在讀取一個沒有偏移量后者偏移量無效(消費者長時間失效當前的偏移量已經(jīng)過時并且被刪除了)的分區(qū)的情況下,應(yīng)該作何處理讥邻,默認值是 latest迫靖,也就是從最新記錄讀取數(shù)據(jù)(消費者啟動之后生成的記錄),另一個值是 earliest兴使,意思是在偏移量無效的情況下系宜,消費者從起始位置開始讀取數(shù)據(jù)。

  • enable.auto.commit: 否自動提交位移发魄,如果為false盹牧,則需要在程序中手動提交位移。對于精確到一次的語義励幼,最好手動提交位移

  • fetch.max.bytes: 單次拉取數(shù)據(jù)的最大字節(jié)數(shù)量

  • max.poll.records: 單次 poll 調(diào)用返回的最大消息數(shù)汰寓,如果處理邏輯很輕量,可以適當提高該值苹粟。 但是max.poll.records條數(shù)據(jù)需要在在 session.timeout.ms 這個時間內(nèi)處理完 有滑。默認值為 500

  • request.timeout.ms: 一次請求響應(yīng)的最長等待時間。如果在超時時間內(nèi)未得到響應(yīng)嵌削,kafka 要么重發(fā)這條消息毛好,要么超過重試次數(shù)的情況下直接置為失敗。

Kafka Rebalance

rebalance 本質(zhì)上是一種協(xié)議掷贾,規(guī)定了一個 consumer group 下的所有 consumer 如何達成一致來分配訂閱 topic 的每個分區(qū)睛榄。比如某個 group 下有 20 個 consumer,它訂閱了一個具有 100 個分區(qū)的 topic想帅。正常情況下场靴,Kafka 平均會為每個 consumer 分配 5 個分區(qū)。這個分配的過程就叫 rebalance港准。

什么時候 rebalance旨剥?

這也是經(jīng)常被提及的一個問題。rebalance 的觸發(fā)條件有三種:

  • 組成員發(fā)生變更(新 consumer 加入組浅缸、已有 consumer 主動離開組或已有 consumer 崩潰了——這兩者的區(qū)別后面會談到)

  • 訂閱主題數(shù)發(fā)生變更

  • 訂閱主題的分區(qū)數(shù)發(fā)生變更

如何進行組內(nèi)分區(qū)分配轨帜?

Kafka 默認提供了兩種分配策略:Range 和 Round-Robin。當然 Kafka 采用了可插拔式的分配策略衩椒,你可以創(chuàng)建自己的分配器以實現(xiàn)不同的分配策略蚌父。

7.1消費者機制中的HW的含義

HW和LEO也有緊密的關(guān)系哮兰。HW是High Watermark的縮寫,俗稱高水位苟弛,它標識了一個特定的消息偏移量(offset)喝滞,消息只能拉取到這個offset之前的消息。

image.png

如上圖所示膏秫,表示一個分區(qū)中各種偏移量的說明右遭。它代表一個日志文件,這個日志文件中有9條消息缤削,第一條消息的offset為0窘哈,最后一條消息的offset為8,offset為9代表下一條待寫入的消息的位置。日志文件的HW為6亭敢,表示消費者只能拉取到offset在0至5之間的消息滚婉,而offset為6的消息對消費者而言是不可見的。LEO是Log End Offset的縮寫吨拗,標識當前日志文件下一條待寫入的消息的offset满哪。分區(qū)ISR集合中的每個副本都會維護自身的的LEO,而集合中最小的LEO即為分區(qū)的HW劝篷,對消費者而言哨鸭,只能消費HW之前的消息娇妓。下面舉個例子來更好的說明ISR集合與HW和LEO之間的關(guān)系:

Leader副本接收到生產(chǎn)者發(fā)送的消息像鸡,寫入本地磁盤后,會更新其LEO值哈恰。 在同步過程中只估,不同的follower副本的同步效率也不盡相同。

image.png

在某一時刻着绷,follower1完全跟上了leader副本而follower2只同步到了消息3蛔钙,如此leader副本的LEO為5,follower1的LEO為5荠医,follower2的LEO為4吁脱,那么當前分區(qū)的HW取最小值4,此時消費者可以消費到offset為0至3之間的消息彬向。

image.png

所有的消息都成功寫入了消息3和消息4兼贡,整個分區(qū)的HW和LEO都變?yōu)?,消費者就可以消費到offset為4的消息了娃胆。由此可見遍希,Kafka的復(fù)制機制既不是完全的同步復(fù)制,也不是單純的異步復(fù)制里烦。同步復(fù)制要求所有能工作的follower副本都復(fù)制完凿蒜,這條消息才會被確認為已成功提交禁谦,這種復(fù)制方式極大地影響了性能。而在異步復(fù)制方式下废封,follower副本異步地從leader副本中復(fù)制數(shù)據(jù)枷畏,數(shù)據(jù)只要被leader副本寫入就被認為已經(jīng)成功提交了。在這種情況下虱饿,如果follower副本都還沒有復(fù)制完而落后于leader副本,突然leader副本宕機触趴,則會造成數(shù)據(jù)丟失氮发。Kafka使用的這種ISR的方式則有效地權(quán)衡了數(shù)據(jù)可靠性和性能之間的關(guān)系。

8冗懦、高可用和性能

分區(qū)和副本

image.png

在分布式數(shù)據(jù)系統(tǒng)中爽冕,通常使用分區(qū)來提高系統(tǒng)的處理能力,通過副本來保證數(shù)據(jù)的高可用性披蕉。多分區(qū)意味著并發(fā)處理的能力颈畸,這多個副本中,只有一個是 leader没讲,而其他的都是 follower 副本眯娱。僅有 leader 副本可以對外提供服務(wù)。 多個 follower 副本通常存放在和 leader 副本不同的 broker 中爬凑。通過這樣的機制實現(xiàn)了高可用徙缴,當某臺機器掛掉后,其他 follower 副本也能迅速”轉(zhuǎn)正“嘁信,開始對外提供服務(wù)于样。

為什么 follower 副本不提供讀服務(wù)?

這個問題本質(zhì)上是對性能和一致性的取舍潘靖。如果 follower 副本也對外提供服務(wù)穿剖,性能是肯定會有所提升的。但同時卦溢,會出現(xiàn)一系列問題糊余。類似數(shù)據(jù)庫事務(wù)中的幻讀,臟讀既绕。 比如你現(xiàn)在寫入一條數(shù)據(jù)到 kafka 主題 a啄刹,消費者 b 從主題 a 消費數(shù)據(jù),卻發(fā)現(xiàn)消費不到凄贩,因為消費者 b 去讀取的那個分區(qū)副本中誓军,最新消息還沒寫入。而這個時候疲扎,另一個消費者 c 卻可以消費到最新那條數(shù)據(jù)昵时,因為它消費了 leader 副本捷雕。Kafka 通過 WH 和 Offset 的管理來決定 Consumer 可以消費哪些數(shù)據(jù),已經(jīng)當前寫入的數(shù)據(jù)壹甥。

這個問題我覺得更加直接的影響是救巷,消費者A從分區(qū)主副本讀到了一個數(shù)據(jù),Offset更新句柠,然后同組另外一個消費者B從分區(qū)的副本讀數(shù)據(jù)浦译,這個時候Offset可能會出現(xiàn)未同步過來的情況,從而導致B會消費到A消費過的消息溯职。而且多副本同時對外服務(wù)最多只能同事對外提供讀服務(wù)精盅,并只能保證最終一致性。如果多副本同事對外提供寫服務(wù)并保證最終一致性谜酒,保證一致性的性能消耗會非常大叹俏,并且需要引入復(fù)雜的類事務(wù)功能,實際上總并發(fā)未必會比單個主副本對外提供服務(wù)搞僻族。

image.png

只有 Leader 可以對外提供讀服務(wù)粘驰,那如何選舉 Leader

   kafka 會將與 leader 副本保持同步的副本放到 ISR 副本集合中。當然述么,leader 副本是一直存在于 ISR 副本集合中的蝌数,在某些特殊情況下,ISR 副本中甚至只有 leader 一個副本碉输。 當 leader 掛掉時籽前,kakfa 通過 zookeeper 感知到這一情況,在 ISR 副本中選取新的副本成為 leader敷钾,對外提供服務(wù)枝哄。 但這樣還有一個問題,前面提到過阻荒,有可能 ISR 副本集合中挠锥,只有 leader,當 leader 副本掛掉后侨赡,ISR 集合就為空蓖租,這時候怎么辦呢?這時候如果設(shè)置 unclean.leader.election.enable 參數(shù)為 true羊壹,那么 kafka 會在非同步蓖宦,也就是不在 ISR 副本集合中的副本中,選取出副本成為 leader油猫。

副本的存在就會出現(xiàn)副本同步問題

Kafka 在所有分配的副本 (AR) 中維護一個可用的副本列表 (ISR)稠茂,Producer 向 Broker 發(fā)送消息時會根據(jù)ack配置來確定需要等待幾個副本已經(jīng)同步了消息才相應(yīng)成功,Broker 內(nèi)部會ReplicaManager服務(wù)來管理 flower 與 leader 之間的數(shù)據(jù)同步。

image.png

性能優(yōu)化

  • partition 并發(fā)

  • 順序讀寫磁盤

  • page cache:按頁讀寫

  • 預(yù)讀:Kafka 會將將要消費的消息提前讀入內(nèi)存

  • 高性能序列化(二進制)

  • 內(nèi)存映射

  • 無鎖 offset 管理:提高并發(fā)能力

  • Java NIO 模型

  • 批量:批量讀寫

  • 壓縮:消息壓縮睬关,存儲壓縮诱担,減小網(wǎng)絡(luò)和 IO 開銷

Partition 并發(fā)

一方面,由于不同 Partition 可位于不同機器电爹,因此可以充分利用集群優(yōu)勢蔫仙,實現(xiàn)機器間的并行處理。另一方面丐箩,由于 Partition 在物理上對應(yīng)一個文件夾摇邦,即使多個 Partition 位于同一個節(jié)點,也可通過配置讓同一節(jié)點上的不同 Partition 置于不同的 disk drive 上屎勘,從而實現(xiàn)磁盤間的并行處理涎嚼,充分發(fā)揮多磁盤的優(yōu)勢。

順序讀寫

Kafka 每一個 partition 目錄下的文件被平均切割成大小相等(默認一個文件是 500 兆挑秉,可以手動去設(shè)置)的數(shù)據(jù)文件,

每一個數(shù)據(jù)文件都被稱為一個段(segment file), 每個 segment 都采用 append 的方式追加數(shù)據(jù)苔货。

9犀概、常見問題

Kafka的關(guān)鍵概念和主要機制

  • 簡單講下 Kafka 的架構(gòu)博助?

    Producer财异、Consumer、Consumer Group赶站、Topic诈茧、Partition

  • Kafka 是推模式還是拉模式产喉,推拉的區(qū)別是什么?

    Kafka Producer 向 Broker 發(fā)送消息使用 Push 模式敢会,Consumer 消費采用的 Pull 模式曾沈。拉取模式,讓 consumer 自己管理 offset鸥昏,可以提供讀取性能

  • Kafka 如何廣播消息塞俱?

    Consumer group

  • Kafka 的消息是否是有序的?

    Topic 級別無序吏垮,Partition 有序

  • Kafka 是否支持讀寫分離障涯?

    不支持,只有 Leader 對外提供讀寫服務(wù)

  • Kafka 如何保證數(shù)據(jù)高可用膳汪?

    副本唯蝶,ack,HW

  • Kafka 中 zookeeper 的作用遗嗽?

    集群管理粘我,元數(shù)據(jù)管理

  • 是否支持事務(wù)?

    0.11 后支持事務(wù)媳谁,可以實現(xiàn)”exactly once“

  • 分區(qū)數(shù)是否可以減少涂滴?

    不可以友酱,會丟失數(shù)據(jù)

Kafka生產(chǎn)者

  • Kafka 有哪些命令行工具?你用過哪些柔纵?/bin目錄缔杉,管理 kafka 集群、管理 topic搁料、生產(chǎn)和消費 kafka

  • Kafka Producer 的執(zhí)行過程或详?攔截器,序列化器郭计,分區(qū)器和累加器

  • Kafka Producer 有哪些常見配置霸琴?broker 配置,ack 配置昭伸,網(wǎng)絡(luò)和發(fā)送參數(shù)梧乘,壓縮參數(shù),ack 參數(shù)

  • 如何讓 Kafka 的消息有序庐杨?Kafka 在 Topic 級別本身是無序的选调,只有 partition 上才有序,所以為了保證處理順序灵份,可以自定義分區(qū)器仁堪,將需順序處理的數(shù)據(jù)發(fā)送到同一個 partition

  • Producer 如何保證數(shù)據(jù)發(fā)送不丟失?ack 機制填渠,重試機制

  • 如何提升 Producer 的性能弦聂?批量,異步氛什,壓縮

Kafka消費者

  • 如果同一 group 下 consumer 的數(shù)量大于 part 的數(shù)量莺葫,kafka 如何處理?多余的 Part 將處于無用狀態(tài)枪眉,不消費數(shù)據(jù)

  • Kafka Consumer 是否是線程安全的徙融?不安全,單線程消費瑰谜,多線程處理

  • 講一下你使用 Kafka Consumer 消費消息時的線程模型欺冀,為何如此設(shè)計?拉取和處理分離

  • Kafka Consumer 的常見配置萨脑?broker, 網(wǎng)絡(luò)和拉取參數(shù)隐轩,心跳參數(shù)

  • Consumer 什么時候會被踢出集群?奔潰渤早,網(wǎng)絡(luò)異常职车,處理時間過長提交位移超時

  • 當有 Consumer 加入或退出時,Kafka 會作何反應(yīng)?進行 Rebalance

  • 什么是 Rebalance悴灵,何時會發(fā)生 Rebalance扛芽?topic 變化,consumer 變化

高性能和高可用

  • Kafka 如何保證高可用积瞒?

    通過副本來保證數(shù)據(jù)的高可用川尖,producer ack、重試茫孔、自動 Leader 選舉叮喳,Consumer 自平衡

  • Kafka 的交付語義?

    交付語義一般有at least once缰贝、at most once和exactly once馍悟。kafka 通過 ack 的配置來實現(xiàn)前兩種。(剩晴?)

  • Replic 的作用锣咒?

    實現(xiàn)數(shù)據(jù)的高可用

  • 什么是 AR,ISR赞弥?

    AR:Assigned Replicas宠哄。AR 是主題被創(chuàng)建后,分區(qū)創(chuàng)建時被分配的副本集合嗤攻,副本個 數(shù)由副本因子決定。

    ISR:In-Sync Replicas诽俯。 AR 中那些與 Leader 保 持同步的副本集合妇菱。在 AR 中的副本可能不在 ISR 中,但 Leader 副本天然就包含在 ISR 中暴区。關(guān)于 ISR闯团,還有一個常見的面試題目是如何判斷副本是否應(yīng)該屬于 ISR。目前的判斷 依據(jù)是:Follower 副本的 LEO 落后 Leader LEO 的時間仙粱,是否超過了 Broker 端參數(shù) replica.lag.time.max.ms 值房交。如果超過了,副本就會被從 ISR 中移除伐割。

  • Leader 和 Flower 是什么候味?

  • Kafka 中的 HW 代表什么?

    高水位值 (High watermark)隔心。這是控制消費者可讀取消息范圍的重要字段白群。一 個普通消費者只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之間的 所有消息。水位以上的消息是對消費者不可見的硬霍。

  • Kafka 為保證優(yōu)越的性能做了哪些處理帜慢?

    partition 并發(fā)、順序讀寫磁盤、page cache 壓縮粱玲、高性能序列化(二進制)躬柬、內(nèi)存映射 無鎖 offset 管理、Java NIO 模型

10抽减、Kafka和Rocketmq的對比

在所有Mq中允青,Kafka和Rocketmq是比較突出和常用的兩個,兩個性能都比較高胯甩,Kafaka在大數(shù)據(jù)方面有很廣泛的應(yīng)用昧廷,而RocketMq在阿里巴巴內(nèi)部經(jīng)歷過雙十一的功能大規(guī)模并發(fā)的考量。

Kafka和RocketMq在文件布局偎箫、數(shù)據(jù)寫入木柬、消息發(fā)送機制方面有不少差異,這些差異導致了兩者比較大的差距

文件布局

Kafka有主題淹办、分區(qū)眉枕、副本的概念,一個主題會有多個分區(qū)怜森,一個分區(qū)會有多個副本但只有主副本對外服務(wù)速挑。不同分區(qū)不同不同的文件存儲數(shù)據(jù),副本還會有彼此獨立的文件存儲數(shù)據(jù)副硅。Kafka會盡量將不同分區(qū)的主副本動態(tài)均衡到不同的機器上提高可靠性姥宝。這樣的機制下會Kafka的讀寫更接近隨機讀寫,能充分利用機器的IO性能恐疲。

image.png

RocketMq的文件布局:

RocketMQ 所有主題的消息都會寫入到 commitlog 文件中腊满,然后基于 commitlog 文件構(gòu)建消息消費隊列文件(Consumequeue),消息消費隊列的組織結(jié)構(gòu)按照 /topic/{queue} 進行組織培己。從集群的視角來看如下圖所示:

image.png

RocketMQ 默認采取的是主從同步碳蛋,當然從RocketMQ4.5引入了多副本機制,但其副本的粒度為 Commitlog 文件省咨,上圖中不同 master 節(jié)點之間的數(shù)據(jù)完成不一樣(數(shù)據(jù)分片)肃弟,而主從節(jié)點節(jié)點數(shù)據(jù)一致。

RocketMQ在消息寫入時追求極致的順序?qū)懥闳兀械南⒉环种黝}一律順序?qū)懭?commitlog 文件笤受,并不會隨著 topic 和 分區(qū)數(shù)量的增加而影響其順序性。

所以可以比較明顯看的出來Kafka的文件布局可以達到更加高效的性能敌蜂。

比較常見常見的結(jié)論是:Kafka 在性能上綜合表現(xiàn)確實要比 RocketMQ 更加的優(yōu)秀感论;從功能性上來考慮,RocketMQ 提供了更豐富的消息檢索功能紊册、事務(wù)消息比肄、消息消費重試快耿、定時消息等。通常在大數(shù)據(jù)芳绩、流式處理場景基本選用 Kafka掀亥,業(yè)務(wù)處理相關(guān)選擇 RocketMQ。

11妥色、Consumer個數(shù)與分區(qū)數(shù)有什么關(guān)系搪花?

topic下的一個分區(qū)只能被同一個consumer group下的一個consumer線程來消費,但反之并不成立嘹害,即一個consumer線程可以消費多個分區(qū)的數(shù)據(jù)撮竿,比如Kafka提供的ConsoleConsumer,默認就只是一個線程來消費所有分區(qū)的數(shù)據(jù)笔呀。即分區(qū)數(shù)決定了同組消費者個數(shù)的上限幢踏。

所以同組消費者數(shù)和分區(qū)保持一致能夠達到最大的吞吐量。超過N的配置只是浪費資源许师,多出的消費者不會被分配到任何分區(qū)房蝉。

參考資料

參考資料(Kafka的主要機制和概念):https://segmentfault.com/a/1190000037455372

參考資料(Kafka的最佳實踐):https://www.infoq.cn/article/4SE0m7cBEFJL_wlfWlUS

參考資料(少數(shù)幾個比較細節(jié)的核心機制):http://www.reibang.com/p/096ec8e97571

參考資料(Kafka和RocketMq的對比):https://blog.csdn.net/prestigeding/article/details/110408415

參考資料(Kafka和RocketMq的核心異同):https://juejin.cn/post/6844903920058236936

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市微渠,隨后出現(xiàn)的幾起案子搭幻,更是在濱河造成了極大的恐慌,老刑警劉巖逞盆,帶你破解...
    沈念sama閱讀 210,914評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件檀蹋,死亡現(xiàn)場離奇詭異,居然都是意外死亡云芦,警方通過查閱死者的電腦和手機俯逾,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,935評論 2 383
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來焕数,“玉大人,你說我怎么就攤上這事刨啸”づ猓” “怎么了?”我有些...
    開封第一講書人閱讀 156,531評論 0 345
  • 文/不壞的土叔 我叫張陵设联,是天一觀的道長善已。 經(jīng)常有香客問我,道長离例,這世上最難降的妖魔是什么换团? 我笑而不...
    開封第一講書人閱讀 56,309評論 1 282
  • 正文 為了忘掉前任,我火速辦了婚禮宫蛆,結(jié)果婚禮上艘包,老公的妹妹穿的比我還像新娘的猛。我一直安慰自己,他們只是感情好想虎,可當我...
    茶點故事閱讀 65,381評論 5 384
  • 文/花漫 我一把揭開白布卦尊。 她就那樣靜靜地躺著,像睡著了一般舌厨。 火紅的嫁衣襯著肌膚如雪岂却。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,730評論 1 289
  • 那天裙椭,我揣著相機與錄音躏哩,去河邊找鬼。 笑死揉燃,一個胖子當著我的面吹牛扫尺,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播你雌,決...
    沈念sama閱讀 38,882評論 3 404
  • 文/蒼蘭香墨 我猛地睜開眼器联,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了婿崭?” 一聲冷哼從身側(cè)響起拨拓,我...
    開封第一講書人閱讀 37,643評論 0 266
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎氓栈,沒想到半個月后渣磷,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,095評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡授瘦,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,448評論 2 325
  • 正文 我和宋清朗相戀三年醋界,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片提完。...
    茶點故事閱讀 38,566評論 1 339
  • 序言:一個原本活蹦亂跳的男人離奇死亡形纺,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出徒欣,到底是詐尸還是另有隱情逐样,我是刑警寧澤,帶...
    沈念sama閱讀 34,253評論 4 328
  • 正文 年R本政府宣布打肝,位于F島的核電站脂新,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏粗梭。R本人自食惡果不足惜争便,卻給世界環(huán)境...
    茶點故事閱讀 39,829評論 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望断医。 院中可真熱鬧滞乙,春花似錦奏纪、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,715評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至浇垦,卻和暖如春炕置,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背男韧。 一陣腳步聲響...
    開封第一講書人閱讀 31,945評論 1 264
  • 我被黑心中介騙來泰國打工朴摊, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人此虑。 一個月前我還...
    沈念sama閱讀 46,248評論 2 360
  • 正文 我出身青樓甚纲,卻偏偏與公主長得像,于是被迫代替她去往敵國和親朦前。 傳聞我的和親對象是個殘疾皇子介杆,可洞房花燭夜當晚...
    茶點故事閱讀 43,440評論 2 348

推薦閱讀更多精彩內(nèi)容