一文讀懂Kafka

2021-02-23    分類: 網(wǎng)站建設(shè)

發(fā)布與訂閱消息系統(tǒng)

在正式討論Apache Kafka (以下簡(jiǎn)稱Kafka)之前,先來(lái)了解發(fā)布與訂閱消息系統(tǒng)的概念, 并認(rèn)識(shí)這個(gè)系統(tǒng)的重要性。數(shù)據(jù)(消息)的發(fā)送者(發(fā)布者)不會(huì)直接把消息發(fā)送給接收 者,這是發(fā)布與訂閱消息系統(tǒng)的一個(gè)特點(diǎn)。發(fā)布者以某種方式對(duì)消息進(jìn)行分類,接收者 (訂閱者)訂閱它們,以便接收特定類型的消息。發(fā)布與訂閱系統(tǒng)一般會(huì)有一個(gè) broker,也就是發(fā)布消息的中心點(diǎn)。

發(fā)布與訂閱消息系統(tǒng)的大部分應(yīng)用場(chǎng)景都是從一個(gè)簡(jiǎn)單的消息隊(duì)列或一個(gè)進(jìn)程間通信開始的。比如電商系統(tǒng)中,包含會(huì)員模塊、訂單模塊、商品模塊、推薦模塊、配送物流模塊等,多個(gè)模塊(子系統(tǒng))間涉及消息的傳遞。

最早的應(yīng)用解決方案就是采用(子系統(tǒng)間)直連的方式,使得很多子系統(tǒng)交錯(cuò)復(fù)雜。這種點(diǎn)對(duì)點(diǎn)的連接方式,形成網(wǎng)狀的連接,弊端很多,不一一贅述。

image

后來(lái),為了解決子系統(tǒng)間直連交錯(cuò)的問題,出現(xiàn)了隊(duì)列系統(tǒng)。下圖所示的架構(gòu)包含了 3 個(gè)獨(dú)立的發(fā)布與訂閱系統(tǒng)。


這種方式比直接使用點(diǎn)對(duì)點(diǎn)的連接要好得多,但這里有太多重復(fù)的地方。你的公司因此要為數(shù)據(jù)隊(duì)列維護(hù)多個(gè)系統(tǒng),每個(gè)系統(tǒng)又有各自的缺陷和不足。而且,接下來(lái)可能會(huì)有更多的場(chǎng)景需要用到消息系統(tǒng)。 此時(shí),你真正需要的是一個(gè)單一的集中式系統(tǒng),它可以用來(lái)發(fā)布通用類型的數(shù)據(jù),其規(guī)??梢噪S著公司業(yè)務(wù)的增長(zhǎng)而增長(zhǎng)。這時(shí)Kafka登場(chǎng)了。

Kafka登場(chǎng)

Kafka就是為了解決上述問題而設(shè)計(jì)的一款基于發(fā)布與訂閱的消息系統(tǒng)。它一般被稱為 “分布式提交日志”或者“分布式流平臺(tái)”。文件系統(tǒng)或數(shù)據(jù)庫(kù)提交日志用來(lái)提供所有事務(wù) 的持久記錄 , 通過重放這些日志可以重建系統(tǒng)的狀態(tài)。同樣地, Kafka 的數(shù)據(jù)是按照 一定順序持久化保存的,可以按需讀取 。 此外, Kafka 的數(shù)據(jù)分布在整個(gè)系統(tǒng)里,具備數(shù)據(jù)故障保護(hù)和性能伸縮能力。

消息和批次

Kafka的數(shù)據(jù)單元被稱為消息。如果你在使用 Kafka之前已經(jīng)有數(shù)據(jù)庫(kù)使用經(jīng)驗(yàn),那么可 以把消息看成是數(shù)據(jù)庫(kù)里的一個(gè)“數(shù)據(jù)行”或一條“記錄”。消息由字節(jié)數(shù)組組成,所以 對(duì)于 Kafka來(lái)說(shuō),消息里的數(shù)據(jù)沒有特別的格式或含義。消息可以有一個(gè)可選的元數(shù)據(jù), 也就是鍵(key)。鍵也是一個(gè)字節(jié)數(shù)組,與消息一樣,對(duì)于 Kafka來(lái)說(shuō)也沒有特殊的含義。 當(dāng)消息以一種可控的方式寫入不同的分區(qū)時(shí),會(huì)用到鍵。最簡(jiǎn)單的例子就是為鍵生成一個(gè)一致 性散列值,然后使用散列值對(duì)主題分區(qū)數(shù)進(jìn)行取模,為消息選取分區(qū) 。這樣可 以保證具有 相同鍵的消息總是被寫到相同的分區(qū)上。

為了提高效率,消息被分批次寫入 Kafka。 批次就是一組消息,這些消息屬于同一個(gè)主題 和分區(qū)。如果每一個(gè)消息都單獨(dú)穿行于網(wǎng)絡(luò),會(huì)導(dǎo)致大量的網(wǎng)絡(luò)開銷,把消息分成批次傳 輸可以減少網(wǎng)絡(luò)開銷。不過,這要在時(shí)間延遲和吞吐量之間作出權(quán)衡;批次越大,單位時(shí)間內(nèi)處理的消息就越多,單個(gè)消息的傳輸時(shí)間就越長(zhǎng)。批次數(shù)據(jù)會(huì)被壓縮,這樣可以提升 數(shù)據(jù)的傳輸和存儲(chǔ)能力,但要做更多的計(jì)算處理。

主題(topic)和分區(qū)(partition)

Kafka 的悄息通過 主題進(jìn)行分類。主題就好比數(shù)據(jù)庫(kù)的表,或者文件系統(tǒng)里的文件夾。主題可以被分為若干個(gè)分區(qū) , 一個(gè)分區(qū)就是一個(gè)提交日志。消息以追加的方式寫入分區(qū),然后以先入先出的順序讀取。要注意,由于一個(gè)主題一般包含幾個(gè)分區(qū),因此無(wú)法在整個(gè)主題范圍內(nèi)保證消息的順序,但可以保證消息在單個(gè)分區(qū)內(nèi)的順序。下圖 所示的主題有 4 個(gè)分區(qū),消息被迫加寫入每個(gè)分區(qū)的尾部。 Kaflca通過分區(qū)來(lái)實(shí)現(xiàn)數(shù)據(jù)冗余和伸縮性。分區(qū)可以分布在不同的服務(wù)器上,也就是說(shuō), 一個(gè)主題可以橫跨多個(gè)服務(wù)器,以此來(lái)提供比 單個(gè)服務(wù)器更強(qiáng)大的性能。


我們通常會(huì)使用流這個(gè)詞來(lái)描繪Kafka這類系統(tǒng)對(duì)數(shù)據(jù)。很多時(shí)候,人們把一個(gè)主題的數(shù)據(jù)看成一個(gè)流,不管它有多少個(gè)分區(qū)。流是一組從生產(chǎn)者移動(dòng)到消費(fèi)者的數(shù)據(jù)。當(dāng)我們討 論流式處理時(shí),一般都是這樣描述消息的。 Kaflca Streams、 Apache Samza 和 Storm 這些框 架以實(shí)時(shí)的方式處理消息,也就是所謂的流式處理。我們可以將流式處理與離線處理進(jìn)行比較,比如 Hadoop 就是被設(shè)計(jì)用于在稍后某個(gè)時(shí)刻處理大量的數(shù)據(jù)。

生產(chǎn)者和消費(fèi)者

Kafka 的客戶端就是 Kafka 系統(tǒng)的用戶,它們被分為兩種基本類型 : 生產(chǎn)者和消費(fèi)者。除此之外,還有其他高級(jí)客戶端 API——用于數(shù)據(jù)集成的 Kaflca Connect API 和用于流式處理 的 Kaflca Streams。這些高級(jí)客戶端 API 使用生產(chǎn)者和消費(fèi)者作為內(nèi)部組件,提供了高級(jí)的 功能。

生產(chǎn)者創(chuàng)建消息。在其他發(fā)布與訂閱系統(tǒng)中,生產(chǎn)者可能被稱為發(fā)布者或?qū)懭胝?。一般?況下,一個(gè)消息會(huì)被發(fā)布到一個(gè)特定的主題(topic)上。生產(chǎn)者在默認(rèn)情況下把消息均衡地分布到主題的所有分區(qū)上,而并不關(guān)心特定消息會(huì)被寫到哪個(gè)分區(qū)。不過,在某些情況下,生產(chǎn)者會(huì)把消息直接寫到指定的分區(qū)。這通常是通過消息鍵和分區(qū)器來(lái)實(shí)現(xiàn)的,分區(qū)器為鍵生 成一個(gè)散列值,并將其映射到指定的分區(qū)上。這樣可以保證包含同一個(gè)鍵的消息會(huì)被寫到 同一個(gè)分區(qū)上。生產(chǎn)者也可以使用自定義的分區(qū)器,根據(jù)不同的業(yè)務(wù)規(guī)則將消息映射到分 區(qū)。下一章將詳細(xì)介紹生產(chǎn)者。

消費(fèi)者讀取消息。在其他發(fā)布與訂閱系統(tǒng)中,消費(fèi)者可能被稱為訂閱者或讀者 。 消費(fèi)者訂閱一個(gè)或多個(gè)主題,并按照消息生成的順序讀取它們。消費(fèi)者通過檢查消息的偏移盤來(lái)區(qū) 分已經(jīng)讀取過的消息。 偏移量是另一種元數(shù)據(jù),它是一個(gè)不斷遞增的整數(shù)值,在創(chuàng)建消息 時(shí), Kafka 會(huì)把它添加到消息里。在給定的分區(qū)里,每個(gè)悄息的偏移量都是唯 一 的。消費(fèi) 者把每個(gè)分區(qū)最后讀取的悄息偏移量保存在 Zookeeper或 Kafka上,如果悄費(fèi)者關(guān)閉或重 啟,它的讀取狀態(tài)不會(huì)丟失。

消費(fèi)者是消費(fèi)者群組的一部分,也就是說(shuō),會(huì)有一個(gè)或多個(gè)消費(fèi)者共同讀取一個(gè)主題。 群組保證每個(gè)分區(qū)只能被一個(gè)消費(fèi)者使用 。下圖所示的群組中,有 3 個(gè)消費(fèi)者同時(shí)讀取一 個(gè)主題。其中的兩個(gè)消費(fèi)者各自讀取一個(gè)分區(qū),另外一個(gè)消費(fèi)者讀取其他兩個(gè)分區(qū)。消費(fèi) 者與分區(qū)之間的映射通常被稱為悄費(fèi)者對(duì)分區(qū)的所有權(quán)關(guān)系 。

通過這種方式,消費(fèi)者可以消費(fèi)包含大量消息的主題。而且,如果一個(gè)消費(fèi)者失效,群組 里的其他消費(fèi)者可以接管失效悄費(fèi)者的工作。第 4章將詳細(xì)介紹消費(fèi)者和悄費(fèi)者群組。


broker和集群

一個(gè)獨(dú)立的 Kafka服務(wù)器被稱為 broker。 broker接收來(lái)自 生產(chǎn)者的消息,為消息設(shè)置偏移 量,并提交消息到磁盤保存。 broker 為消費(fèi)者提供服務(wù),對(duì)讀取分區(qū)的請(qǐng)求作出響應(yīng),返 回已經(jīng)提交到磁盤上的消息。根據(jù)特定的硬件及其性能特征,單個(gè) broker可以輕松處理數(shù) 千個(gè)分區(qū)以及每秒百萬(wàn)級(jí)的消息量。

Broker可以看作是消息中間件處理節(jié)點(diǎn),一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)broker,一個(gè)或者多個(gè)Broker可以組成一個(gè)Kafka集群。

broker是集群的組成部分。每個(gè)集群都有一個(gè) broker 同時(shí)充當(dāng)了集群控制器的角色(自動(dòng) 從集群的活躍成員中選舉出來(lái))??刂破髫?fù)責(zé)管理工作,包括將分區(qū)分配給 broker和監(jiān)控 broker. 在集群中, 一個(gè)分區(qū)從屬于一個(gè) broker, i亥 broker被稱為分區(qū)的首領(lǐng)。一個(gè)分區(qū) 可以分配給多個(gè) broker,這個(gè)時(shí)候會(huì)發(fā)生分區(qū)復(fù)制(見下圖)。這種復(fù)制機(jī)制為分區(qū)提供 了消息冗余,如果有一個(gè) broker失效,其他 broker可以接管領(lǐng)導(dǎo)權(quán)。不過,相關(guān)的消費(fèi)者 和生產(chǎn)者都要重新連接到新的首領(lǐng)。


保留消息(在一定期限內(nèi))是 Kafka的一個(gè)重要特性。 Kafka broker默認(rèn)的消息保留策略 是這樣的:要么保留一段時(shí)間(比如 7天),要么保留到消息達(dá)到一定大小的字節(jié)數(shù)(比 如 1GB)。當(dāng)消息數(shù)量達(dá)到這些上限時(shí),舊消息就會(huì)過期井被刪除,所以在任何時(shí)刻, 可 用消息的總量都不會(huì)超過配置參數(shù)所指定的大小。主題可以配置自己的保留策略,可以將 悄息保留到不再使用它們?yōu)橹?。例如,用于跟蹤用戶活?dòng)的數(shù)據(jù)可能需要保留幾天,而應(yīng) 用程序的度量指標(biāo)可能只需要保留幾個(gè)小時(shí)??梢酝ㄟ^配置把主題當(dāng)作 緊湊型日志, 只有 最后一個(gè)帶有特定鍵的消息會(huì)被保留下來(lái)。這種情況對(duì)于變更日志類型的數(shù)據(jù)來(lái)說(shuō)比較適 用,因?yàn)槿藗冎魂P(guān)心最后時(shí)刻發(fā)生的那個(gè)變更。

為什么選擇 Kafka

多個(gè)生產(chǎn)者

Kafka 可以無(wú)縫地支持多個(gè)生產(chǎn)者,不管客戶端在使用單個(gè) 主題還是多個(gè)主題。所以它很 適合用來(lái)從多個(gè)前端系統(tǒng)收集數(shù)據(jù),并以統(tǒng)一的格式對(duì)外提供數(shù)據(jù)。例如, 一個(gè)包含了 多 個(gè)微服務(wù)的網(wǎng)站,可以為頁(yè)面視圖創(chuàng)建一個(gè)單獨(dú)的主題,所有服務(wù)都以相同的消息格式向 該主題寫入數(shù)據(jù)。消費(fèi)者應(yīng)用程序會(huì)獲得統(tǒng)一的頁(yè)面視圖,而無(wú)需協(xié)調(diào)來(lái)自不同生產(chǎn)者的 數(shù)據(jù)流。

多個(gè)消費(fèi)者

除了支持多個(gè)生產(chǎn)者外, Kafka也支持多個(gè)消費(fèi)者從一個(gè)單獨(dú)的消息流上讀取數(shù)據(jù),而且 消費(fèi)者之間直不影響。這與其他隊(duì)列系統(tǒng)不同,其他隊(duì)列系統(tǒng)的消息一旦被一個(gè)客戶端讀 取,其他客戶端就無(wú)法再讀取它。另外,多個(gè)消費(fèi)者可以組成一個(gè)群組,它們共享一個(gè)消息流,并保證整個(gè)群組對(duì)每個(gè)給定的消息只處理一次。

基于磁盤的數(shù)據(jù)存儲(chǔ)

Kafka不僅支持多個(gè)消費(fèi)者,還允許消費(fèi)者非實(shí)時(shí)地讀取消息,這要?dú)w功于 Kafka的數(shù)據(jù) 保留特性。?肖息被提交到磁盤,根據(jù)設(shè)置的保留規(guī)則進(jìn)行保存。每個(gè)主題可以設(shè)置單獨(dú)的 保留規(guī)則,以便滿足不同消費(fèi)者的需求,各個(gè)主題可以保留不同數(shù)量的消息。消費(fèi)者可能 會(huì)因?yàn)樘幚硭俣嚷蛲话l(fā)的流量高峰導(dǎo)致無(wú)陸及時(shí)讀取消息,而持久化數(shù)據(jù)可以保證數(shù)據(jù) 不會(huì)丟失。?肖費(fèi)者可以在進(jìn)行應(yīng)用程序維護(hù)時(shí)離線一小段時(shí)間,而無(wú)需擔(dān)心消息丟失或堵 塞在生產(chǎn)者端。 消費(fèi)者可以被關(guān)閉,但消息會(huì)繼續(xù)保留在 Kafka里。消費(fèi)者可以從上次中 斷的地方繼續(xù)處理消息。

伸縮性

為了能夠輕松處理大量數(shù)據(jù), Kafka 從一開始就被設(shè)計(jì)成一個(gè)具有靈活伸縮性的系統(tǒng)。用 戶在開發(fā)階段可以先使用單個(gè) broker,再擴(kuò)展到包含 3 個(gè) broker 的小型開發(fā)集群,然后隨 著數(shù)據(jù)鹽不斷增長(zhǎng),部署到生產(chǎn)環(huán)境的集群可能包含上百個(gè) broker。對(duì)在線集群進(jìn)行擴(kuò)展 絲毫不影響整體系統(tǒng)的可用性。也就是說(shuō), 一個(gè)包含多個(gè) broker的集群,即使個(gè)別 broker 失效,仍然可以持續(xù)地為客戶提供服務(wù)。要提高集群的容錯(cuò)能力,需要配置較高的復(fù)制系 數(shù)。

高性能

上面提到的所有特性,讓 Kafka成為了一個(gè)高性能的發(fā)布與訂閱消息系統(tǒng)。通過橫向擴(kuò)展 生產(chǎn)者、消費(fèi)者和 broker, Kafka可以輕松處理巨大的消息流。在處理大量數(shù)據(jù)的同時(shí), 它還能保證亞秒級(jí)的消息延遲。

分享文章:一文讀懂Kafka
文章分享:http://www.muchs.cn/news37/102487.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)網(wǎng)站建設(shè)、微信小程序、品牌網(wǎng)站設(shè)計(jì)響應(yīng)式網(wǎng)站、定制網(wǎng)站、外貿(mào)建站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

成都定制網(wǎng)站建設(shè)