【Kafka】《Kafka權威指南》入門

發佈與訂閱消息系統

在正式討論Apache Kafka (如下簡稱Kafka)以前，先來了解發布與訂閱消息系統的概念， 並認識這個系統的重要性。數據(消息)的發送者(發佈者)不會直接把消息發送給接收 者，這是發佈與訂閱消息系統的一個特色。發佈者以某種方式對消息進行分類，接收者 (訂閱者)訂閱它們，以便接收特定類型的消息。發佈與訂閱系統通常會有一個 broker，也就是發佈消息的中心點。

發佈與訂閱消息系統的大部分應用場景都是從一個簡單的消息隊列或一個進程間通訊開始的。好比電商系統中，包含會員模塊、訂單模塊、商品模塊、推薦模塊、配送物流模塊等，多個模塊(子系統)間涉及消息的傳遞。

最先的應用解決方案就是採用(子系統間)直連的方式，使得不少子系統交錯複雜。這種點對點的鏈接方式，造成網狀的鏈接，弊端不少，不一一贅述。

後來，爲了解決子系統間直連交錯的問題，出現了隊列系統。下圖所示的架構包含了 3 個獨立的發佈與訂閱系統。

這種方式比直接使用點對點的鏈接要好得多，但這裏有太多重複的地方。你的公司所以要爲數據隊列維護多個系統，每一個系統又有各自的缺陷和不足。並且，接下來可能會有更多的場景須要用到消息系統。 此時，你真正須要的是一個單一的集中式系統，它能夠用來發布通用類型的數據，其規模能夠隨着公司業務的增加而增加。這時Kafka登場了。

Kafka登場

Kafka就是爲了解決上述問題而設計的一款基於發佈與訂閱的消息系統。它通常被稱爲 「分佈式提交日誌」或者「分佈式流平臺」。文件系統或數據庫提交日誌用來提供全部事務 的持久記錄 ， 經過重放這些日誌能夠重建系統的狀態。一樣地， Kafka 的數據是按照 必定順序持久化保存的，能夠按需讀取 。 此外， Kafka 的數據分佈在整個系統裏，具有數據故障保護和性能伸縮能力。

消息和批次

Kafka的數據單元被稱爲消息。若是你在使用 Kafka以前已經有數據庫使用經驗，那麼可 以把消息當作是數據庫裏的一個「數據行」或一條「記錄」。消息由字節數組組成，因此 對於 Kafka來講，消息裏的數據沒有特別的格式或含義。消息能夠有一個可選的元數據， 也就是鍵(key)。鍵也是一個字節數組，與消息同樣，對於 Kafka來講也沒有特殊的含義。 當消息以一種可控的方式寫入不一樣的分區時，會用到鍵。最簡單的例子就是爲鍵生成一個一致 性散列值，而後使用散列值對主題分區數進行取模，爲消息選取分區 。這樣可 以保證具備 相同鍵的消息老是被寫到相同的分區上。

爲了提升效率，消息被分批次寫入 Kafka。 批次就是一組消息，這些消息屬於同一個主題 和分區。若是每個消息都單獨穿行於網絡，會致使大量的網絡開銷，把消息分紅批次傳 輸能夠減小網絡開銷。不過，這要在時間延遲和吞吐量之間做出權衡；批次越大，單位時間內處理的消息就越多，單個消息的傳輸時間就越長。批次數據會被壓縮，這樣能夠提高 數據的傳輸和存儲能力，但要作更多的計算處理。

主題(topic)和分區(partition)

Kafka 的悄息經過 主題進行分類。主題就比如數據庫的表，或者文件系統裏的文件夾。主題能夠被分爲若干個分區 ， 一個分區就是一個提交日誌。消息以追加的方式寫入分區，而後以先入先出的順序讀取。要注意，因爲一個主題通常包含幾個分區，所以沒法在整個主題範圍內保證消息的順序，但能夠保證消息在單個分區內的順序。下圖 所示的主題有 4 個分區，消息被迫加寫入每一個分區的尾部。 Kaflca經過分區來實現數據冗餘和伸縮性。分區能夠分佈在不一樣的服務器上，也就是說， 一個主題能夠橫跨多個服務器，以此來提供比 單個服務器更強大的性能。

咱們一般會使用流這個詞來描繪Kafka這類系統對數據。不少時候，人們把一個主題的數據當作一個流，無論它有多少個分區。流是一組從生產者移動到消費者的數據。當咱們討 論流式處理時，通常都是這樣描述消息的。 Kaflca Streams、 Apache Samza 和 Storm 這些框 架以實時的方式處理消息，也就是所謂的流式處理。咱們能夠將流式處理與離線處理進行比較，好比 Hadoop 就是被設計用於在稍後某個時刻處理大量的數據。

生產者和消費者

Kafka 的客戶端就是 Kafka 系統的用戶，它們被分爲兩種基本類型 : 生產者和消費者。除此以外，還有其餘高級客戶端 API——用於數據集成的 Kaflca Connect API 和用於流式處理 的 Kaflca Streams。這些高級客戶端 API 使用生產者和消費者做爲內部組件，提供了高級的 功能。

生產者建立消息。在其餘發佈與訂閱系統中，生產者可能被稱爲發佈者或寫入者。通常情 況下，一個消息會被髮布到一個特定的主題(topic)上。生產者在默認狀況下把消息均衡地分佈到主題的全部分區上，而並不關心特定消息會被寫到哪一個分區。不過，在某些狀況下，生產者會把消息直接寫到指定的分區。這一般是經過消息鍵和分區器來實現的，分區器爲鍵生 成一個散列值，並將其映射到指定的分區上。這樣能夠保證包含同一個鍵的消息會被寫到 同一個分區上。生產者也可使用自定義的分區器，根據不一樣的業務規則將消息映射到分 區。下一章將詳細介紹生產者。

消費者讀取消息。在其餘發佈與訂閱系統中，消費者可能被稱爲訂閱者或讀者 。 消費者訂閱一個或多個主題，並按照消息生成的順序讀取它們。消費者經過檢查消息的偏移盤來區 分已經讀取過的消息。 偏移量是另外一種元數據，它是一個不斷遞增的整數值，在建立消息 時， Kafka 會把它添加到消息裏。在給定的分區裏，每一個悄息的偏移量都是惟 一 的。消費 者把每一個分區最後讀取的悄息偏移量保存在 Zookeeper或 Kafka上，若是悄費者關閉或重 啓，它的讀取狀態不會丟失。

消費者是消費者羣組的一部分，也就是說，會有一個或多個消費者共同讀取一個主題。 羣組保證每一個分區只能被一個消費者使用 。下圖所示的羣組中，有 3 個消費者同時讀取一 個主題。其中的兩個消費者各自讀取一個分區，另一個消費者讀取其餘兩個分區。消費 者與分區之間的映射一般被稱爲悄費者對分區的全部權關係 。

經過這種方式，消費者能夠消費包含大量消息的主題。並且，若是一個消費者失效，羣組 裏的其餘消費者能夠接管失效悄費者的工做。第 4章將詳細介紹消費者和悄費者羣組。

 

broker和集羣

一個獨立的 Kafka服務器被稱爲 broker。 broker接收來自 生產者的消息，爲消息設置偏移 量，並提交消息到磁盤保存。 broker 爲消費者提供服務，對讀取分區的請求做出響應，返 回已經提交到磁盤上的消息。根據特定的硬件及其性能特徵，單個 broker能夠輕鬆處理數 千個分區以及每秒百萬級的消息量。

Broker能夠看做是消息中間件處理節點，一個Kafka節點就是一個broker，一個或者多個Broker能夠組成一個Kafka集羣。

broker是集羣的組成部分。每一個集羣都有一個 broker 同時充當了集羣控制器的角色(自動 從集羣的活躍成員中選舉出來)。控制器負責管理工做，包括將分區分配給 broker和監控 broker. 在集羣中， 一個分區從屬於一個 broker, i亥 broker被稱爲分區的首領。一個分區 能夠分配給多個 broker，這個時候會發生分區複製(見下圖)。這種複製機制爲分區提供 了消息冗餘，若是有一個 broker失效，其餘 broker能夠接管領導權。不過，相關的消費者 和生產者都要從新鏈接到新的首領。

保留消息(在必定期限內)是 Kafka的一個重要特性。 Kafka broker默認的消息保留策略 是這樣的：要麼保留一段時間(好比 7天)，要麼保留到消息達到必定大小的字節數(比 如 1GB)。當消息數量達到這些上限時，舊消息就會過時井被刪除，因此在任什麼時候刻， 可 用消息的總量都不會超過配置參數所指定的大小。主題能夠配置本身的保留策略，能夠將 悄息保留到再也不使用它們爲止。例如，用於跟蹤用戶活動的數據可能須要保留幾天，而應 用程序的度量指標可能只須要保留幾個小時。能夠經過配置把主題看成 緊湊型日誌， 只有 最後一個帶有特定鍵的消息會被保留下來。這種狀況對於變動日誌類型的數據來講比較適 用，由於人們只關心最後時刻發生的那個變動。
 

爲何選擇 Kafka

多個生產者

Kafka 能夠無縫地支持多個生產者，無論客戶端在使用單個 主題仍是多個主題。因此它很 適合用來從多個前端系統收集數據，並以統一的格式對外提供數據。例如， 一個包含了 多 個微服務的網站，能夠爲頁面視圖建立一個單獨的主題，全部服務都以相同的消息格式向 該主題寫入數據。消費者應用程序會得到統一的頁面視圖，而無需協調來自不一樣生產者的 數據流。

多個消費者

除了支持多個生產者外， Kafka也支持多個消費者從一個單獨的消息流上讀取數據，並且 消費者之間直不影響。這與其餘隊列系統不一樣，其餘隊列系統的消息一旦被一個客戶端讀 取，其餘客戶端就沒法再讀取它。另外，多個消費者能夠組成一個羣組，它們共享一個消息流，並保證整個羣組對每一個給定的消息只處理一次。

基於磁盤的數據存儲

Kafka不只支持多個消費者，還容許消費者非實時地讀取消息，這要歸功於 Kafka的數據 保留特性。?肖息被提交到磁盤，根據設置的保留規則進行保存。每一個主題能夠設置單獨的 保留規則，以便知足不一樣消費者的需求，各個主題能夠保留不一樣數量的消息。消費者可能 會由於處理速度慢或突發的流量高峯致使無陸及時讀取消息，而持久化數據能夠保證數據 不會丟失。?肖費者能夠在進行應用程序維護時離線一小段時間，而無需擔憂消息丟失或堵 塞在生產者端。 消費者能夠被關閉，但消息會繼續保留在 Kafka裏。消費者能夠從上次中 斷的地方繼續處理消息。

伸縮性

爲了可以輕鬆處理大量數據， Kafka 從一開始就被設計成一個具備靈活伸縮性的系統。用 戶在開發階段能夠先使用單個 broker，再擴展到包含 3 個 broker 的小型開發集羣，而後隨 着數據鹽不斷增加，部署到生產環境的集羣可能包含上百個 broker。對在線集羣進行擴展 絲絕不影響總體系統的可用性。也就是說， 一個包含多個 broker的集羣，即便個別 broker 失效，仍然能夠持續地爲客戶提供服務。要提升集羣的容錯能力，須要配置較高的複製系 數。

高性能

上面提到的全部特性，讓 Kafka成爲了一個高性能的發佈與訂閱消息系統。經過橫向擴展 生產者、消費者和 broker, Kafka能夠輕鬆處理巨大的消息流。在處理大量數據的同時， 它還能保證亞秒級的消息延遲。