Categories
程式開發

Kafka權威指南(二):為什麼選擇Kafka


編者按:本文節選自圖靈程序設計叢書 《Kafka權威指南》一書中的部分章節。

為什麼選擇Kafka

基於發布與訂閱的消息系統那麼多,為什麼 Kafka 會是一個更好的選擇呢?

多個生產者

Kafka 可以無縫地支持多個生產者,不管客戶端在使用單個主題還是多個主題。所以它很適合用來從多個前端系統收集數據,並以統一的格式對外提供數據。例如,一個包含了多個微服務的網站,可以為頁面視圖創建一個單獨的主題,所有服務都以相同的消息格式向該主題寫入數據。消費者應用程序會獲得統一的頁面視圖,而無需協調來自不同生產者的數據流。

多個消費者

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

基於磁盤的數據存儲

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

伸縮性

為了能夠輕鬆處理大量數據,Kafka 從一開始就被設計成一個具有靈活伸縮性的系統。用戶在開發階段可以先使用單個 broker,再擴展到包含 3 個 broker 的小型開發集群,然後隨著數據量不斷增長,部署到生產環境的集群可能包含上百個 broker。對在線集群進行擴展絲毫不影響整體系統的可用性。也就是說,一個包含多個 broker 的集群,即使個別 broker 失效,仍然可以持續地為客戶提供服務。要提高集群的容錯能力,需要配置較高的複制係數。第 6 章將討論關於復制的更多細節。

高性能

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

數據生態系統

已經有很多應用程序加入到了數據處理的大軍中。我們定義了輸入和應用程序,負責生成數據或者把數據引入系統。我們定義了輸出,它們可以是度量指標、報告或者其他類型的數據。我們創建了一些循環,使用一些組件從系統讀取數據,對讀取的數據進行處理,然後把它們導到數據基礎設施上,以備不時之需。數據類型可以多種多樣,每一種數據類型可以有不同的內容、大小和用途。

Kafka 為數據生態系統帶來了循環系統,如圖 1 所示。它在基礎設施的各個組件之間傳遞消息,為所有客戶端提供一致的接口。當與提供消息模式的系統集成時,生產者和消費者之間不再有緊密的耦合,也不需要在它們之間建立任何類型的直連。我們可以根據業務需要添加或移除組件,因為生產者不再關心誰在使用數據,也不關心有多少個消費者。

Kafka權威指南(二):為什麼選擇Kafka 1

圖 1:大數據生態系統

使用場景

  1. 活動跟踪

    Kafka 最初的使用場景是跟踪用戶的活動。網站用戶與前端應用程序發生交互,前端應用程序生成用戶活動相關的消息。這些消息可以是一些靜態的信息,比如頁面訪問次數和點擊量,也可以是一些複雜的操作,比如添加用戶資料。這些消息被發佈到一個或多個主題上,由後端應用程序負責讀取。這樣,我們就可以生成報告,為機器學習系統提供數據,更新搜索結果,或者實現其他更多的功能。

  2. 傳遞消息

    Kafka 的另一個基本用途是傳遞消息。應用程序向用戶發送通知(比如郵件)就是通過傳遞消息來實現的。這些應用程序組件可以生成消息,而不需要關心消息的格式,也不需要關心消息是如何被發送的。一個公共應用程序會讀取這些消息,對它們進行處理:

    • 格式化消息(也就是所謂的裝飾);
    • 將多個消息放在同一個通知裡發送;
    • 根據用戶配置的首選項來發送數據。

    使用公共組件的好處在於,不需要在多個應用程序上開發重複的功能,而且可以在公共組件上做一些有趣的轉換,比如把多個消息聚合成一個單獨的通知,而這些工作是無法在其他地方完成的。

  3. 度量指標和日誌記錄

    Kafka 也可以用於收集應用程序和系統度量指標以及日誌。 Kafka 支持多個生產者的特性在這個時候就可以派上用場。應用程序定期把度量指標發佈到 Kafka 主題上,監控系統或告警系統讀取這些消息。 Kafka 也可以用在像 Hadoop 這樣的離線系統上,進行較長時間片段的數據分析,比如年度增長走勢預測。日誌消息也可以被發佈到 Kafka 主題上,然後被路由到專門的日誌搜索系統(比如 Elasticsearch)或安全分析應用程序。更改目標系統(比如日誌存儲系統)不會影響到前端應用或聚合方法,這是 Kafka 的另一個優點。

  4. 提交日誌

    Kafka 的基本概念來源於提交日誌,所以使用 Kafka 作為提交日誌是件順理成章的事。我們可以把數據庫的更新發佈到 Kafka 上,應用程序通過監控事件流來接收數據庫的實時更新。這種變更日誌流也可以用於把數據庫的更新復製到遠程系統上,或者合併多個應用程序的更新到一個單獨的數據庫視圖上。數據持久化為變更日誌提供了緩衝區,也就是說,如果消費者應用程序發生故障,可以通過重放這些日誌來恢復系統狀態。另外,緊湊型日誌主題只為每個鍵保留一個變更數據,所以可以長時間使用,不需要擔心消息過期問題。

  5. 流處理

    流處理是又一個能提供多種類型應用程序的領域。可以說,它們提供的功能與Hadoop 裡的map 和reduce 有點類似,只不過它們操作的是實時數據流,而Hadoop 則處理更長時間片段的數據,可能是幾個小時或者幾天,Hadoop 會對這些數據進行批處理。通過使用流式處理框架,用戶可以編寫小型應用程序來操作 Kafka 消息,比如計算度量指標,為其他應用程序有效地處理消息分區,或者對來自多個數據源的消息進行轉換。第 11 章將通過其他案例介紹流處理。

圖書簡介https://www.ituring.com.cn/book/2067

Kafka權威指南(二):為什麼選擇Kafka 2

相關閱讀

Kafka權威指南(一):初識Kafka