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有管理后臺
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ā)讀寫。
通過Offset記錄不同消費者組消費到的最新信息必指,Offset是信息在單個分區(qū)里的唯一標識
Kafka通過Zookeeper管理多個Boker并保障服務(wù)的高可用
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.sh和kafka-console-producer.sh腳本來測試 Kafka 生產(chǎn)和消費药蜻,kafka-consumer-groups.sh可以查看和管理集群中的 Topic,kafka-topics.sh通常用于查看 Kafka 的消費組情況替饿。
6语泽、Kafka 生產(chǎn)者重要機制
Kafka producer 的正常生產(chǎn)邏輯包含以下幾個步驟:
配置生產(chǎn)者客戶端參數(shù)創(chuàng)建生產(chǎn)者實例。
構(gòu)建待發(fā)送的消息视卢。
發(fā)送消息踱卵。
關(guān)閉生產(chǎn)者實例。
Producer 發(fā)送消息的過程如下圖所示,需要經(jīng)過攔截器惋砂,序列化器和分區(qū)器妒挎,最終由累加器批量發(fā)送至 Broker。
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ù)的效率茂蚓。
-
默認值: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ù)钠怯。
-
默認值:300,每次嘗試增加的額外的間隔時間曙聂。
-
topic.metadata.refresh.interval.ms
默認值:600000晦炊,定期的獲取元數(shù)據(jù)的時間。當分區(qū)丟失筹陵,leader 不可用時 producer 也會主動獲取元數(shù)據(jù)刽锤,如果為 0,則每次發(fā)送完消息就獲取元數(shù)據(jù)朦佩,不推薦并思。如果為負值,則只有在失敗的情況下獲取元數(shù)據(jù)语稠。
-
默認值:5000宋彼,在 producer queue 的緩存的數(shù)據(jù)最大時間,僅僅 for asyc仙畦。
-
queue.buffering.max.message
默認值:10000输涕,producer 緩存的消息的最大數(shù)量,僅僅 for asyc慨畸。
-
默認值:-1莱坎,0 當 queue 滿時丟掉,負值是 queue 滿時 block, 正值是 queue 滿時 block 相應(yīng)的時間寸士,僅僅 for asyc檐什。
7、Kafka消費者機制
Kafka 有消費組的概念弱卡,每個消費者只能消費所分配到的分區(qū)的消息乃正,每一個分區(qū)只能被一個消費組中的一個消費者所消費,所以同一個消費組中消費者的數(shù)量如果超過了分區(qū)的數(shù)量婶博,將會出現(xiàn)有些消費者分配不到消費的分區(qū)瓮具。消費組與消費者關(guān)系如下圖所示:
Kafka Consumer Client 消費消息通常包含以下步驟:
配置客戶端,創(chuàng)建消費者
訂閱主題
拉去消息并消費
提交消費位移
關(guān)閉消費者實例
因為 Kafka 的 Consumer 客戶端是線程不安全的凡人,為了保證線程安全名党,并提升消費性能,可以在 Consumer 端采用類似 Reactor 的線程模型來消費數(shù)據(jù)挠轴。
消費者常用參數(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之前的消息。
如上圖所示膏秫,表示一個分區(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副本的同步效率也不盡相同。
在某一時刻着绷,follower1完全跟上了leader副本而follower2只同步到了消息3蛔钙,如此leader副本的LEO為5,follower1的LEO為5荠医,follower2的LEO為4吁脱,那么當前分區(qū)的HW取最小值4,此時消費者可以消費到offset為0至3之間的消息彬向。
所有的消息都成功寫入了消息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ū)和副本
在分布式數(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ù)搞僻族。
只有 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ù)同步。
性能優(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性能恐疲。
RocketMq的文件布局:
RocketMQ 所有主題的消息都會寫入到 commitlog 文件中腊满,然后基于 commitlog 文件構(gòu)建消息消費隊列文件(Consumequeue),消息消費隊列的組織結(jié)構(gòu)按照 /topic/{queue} 進行組織培己。從集群的視角來看如下圖所示:
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