一文讀懂Kafka

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

Kafka登場

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

消息和批次

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

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

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

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

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

生產(chǎn)者和消費者

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

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

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

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

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

broker和集群

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

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

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

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

為什么選擇 Kafka

多個生產(chǎn)者

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

多個消費者

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

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

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

伸縮性

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

高性能

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

分享文章：一文讀懂Kafka
文章分享：http://www.bm7419.com/news37/102487.html

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

廣告

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