Kafka學習分享

.1 什麽是Kafka

Apache Kafka是一個開源的流處理平臺，由 Apache Software Foundation使用Scala and Java編寫發展而來。Kafka?用於構建實時數據管道和流媒體應用。 它具有水平可擴展性，容錯性，快速性，並在數千家公司生產中運行。

它的主要功能：數據流的發布和訂閱、數據流的處理、數據流的存儲。像一個消息系統一樣發布和訂閱數據流，有效且實時地處理數據流，在一個分布式備份的集群中安全地處理存儲數據流。

.2 Kafka詳細介紹

.2.1 流處理平臺的三個關鍵功能

l 它允許發布和訂閱可記錄的流。在這個方面，它類似於一個消息隊列或者一個企業消息系統。

l 它允許以一種容錯的方式存儲可記錄的流。

l 它允許當可記錄的流發生的時候來處理它們。

.2.2 Kafka的好處是什麽？

它被用於兩類廣泛的應用程序：

l 構建能夠可靠地在系統和應用程序之間獲取數據的實時流數據管道。

l 構建對流數據轉換和響應的實時流應用程序。

.2.3 Kafka是如何運行的？

為了理解Kafka是怎樣做這些事情的，讓我們自下而上深入探索Kafka的能力。

一些概念

l Kafka作為一個集群在一個或多個服務器上運行；

l Kafka集群存儲可記錄的流的類別，稱為topics；

l 每條記錄包含一個key，一個value和一個timestamp；

Kafka有四個核心的APIs

l Producer API 允許一個應用程序將一條可記錄的流發布到一個或多個Kafka topics.

l Consumer API 允許一個應用程序訂閱一個或多個Kafka topics，並且處理生成給它們的可記錄流。

l Streams API允許一個應用程序扮演一個流處理器，消費來自一個或多個topics的輸入流並且生產輸出流給一個或多個topics，有效地將輸入流轉換成輸出流。

l Connector API允許構建和運行可復用的，將Kafka topics和現有應用程序或數據系統連接起來的生產者或消費者。如，一個相關數據的連機器可能捕獲一張表的每一個變化。

在Kafka中，客戶端和服務端之間的通信是由一個簡單的、高性能的、跨語言的TCP協議完成的。這種協議是版本控制的，並且與舊版本保持後向兼容。我們提供了一個Java客戶端給Kafka，但是客戶端支持多種語言。

Topics and Logs

一個Topic 就是記錄被發布的一個類別或者提要名稱。Kafka 的topics總是多訂閱用戶的，換句話說，一個topic可以有0個、一個、或多個訂閱了它的數據的消費者。

對於每一個topic，Kafka集群保持一個分區的log，如下圖：

每一個分區都是一個有序的，不變的可記錄的序列，這些序列不斷地添加到一個結構化的提交日誌中。分區的記錄各自都被分配一個連續的ID號，被稱為偏移量，偏移量在分區中唯一標識每條記錄。

Kafka集群保留所有發布的記錄無論他們是否被消費，使用一個可配置的保留期。例如：如果保留策略設置為兩天，然後在一個記錄被發布後的兩天之內，它可以用於消費，之後它將被丟棄以釋放空間。Kafka可以存儲很長時間的數據且性能不受數據量大小的影響。

事實上，在每一個消費者基礎上保留的唯一的元數據是日誌中消費者的偏移量或者位置。這個偏移量是由消費者控制的：通常，消費者會線性地提高它的偏移量來讀取記錄，但是，事實上，由於位置是由消費者控制的，消費者可以按照它想要的任何順序來消費記錄。例如，一個消費者可以重新設置為舊的偏移量，以重新處理過去的數據，或者跳到最近的記錄，並從“now”開始消費。

這種組合的特性意味著Kafka消費者是非常便宜的，他們的來去不會對集群或者其他的消費者產生一些影響。例如：你能夠使用我們的命令行工具來“tail”任何topic的內容，而不需要改變任何被現有消費者消費的內容。

日誌中的分區有幾個目的。首先，他們允許日誌擴展到超出一個適合單個服務器的大小。每個獨立的分區必須適合承載它的服務器，但是一個topic應該有許多的分區，，因此它能夠處理任意數量的數據。其次，他們作為一個並行的單元，在這方面做的更多。

分布式

日誌的分區分布在Kafka集群中不同的服務器上，每個服務器處理數據並請求共享分區。每個分區在一個可配置數量的服務器上進行復用，用於容錯。

每個分區有一個作為“leader”的服務器和0個或多個作為“followers”的服務器。主服務器處理該分區的所有讀寫請求，而從服務器被動地復制主服務器。如果主服務器出現故障，那麽其他從服務器中的一個將自動成為新的主服務器。每個服務器充當某些分區的領導者，並為其他一些分區提供一個追隨者，因此在集群中負載均衡。

生產者

生產者發布它們選擇的數據給每個topics。生產者負責在topic中選擇哪條記錄分配到哪個分區上。這可以以循環的方式簡單實現負載均衡或者它可以根據一些語義分區函數（據說是根據記錄上的一些關鍵字）來完成。

消費者

消費者給自己貼上一個消費者團體的標簽，每個被發布到一個topic的記錄都被交付到每個訂閱消費者團體中的一個消費者實例。消費者實例可以在單獨的進程中，也可以在單獨的機器上。

如果所有的消費者實例有相同的消費者團體，然後這些記錄將在這些消費者實例中有效地實現負載均衡。

如果所有的消費者實例有不同的消費者團體，然後每個記錄將被廣播到所有的消費者進程中。

一個兩個服務器的Kafka集群承載4個分區（P0-P3），其中有兩個消費者團體。消費者團體A有兩個消費者實例，並且消費者團體B有四個消費者實例。

然而，更常見的是，我們發現有少量消費者群體的topics，每個消費者都是“logical subscriber”。每個團體有許多用於可伸縮性和容錯的消費者實例組成。這只不過是，訂閱-發布語法，訂閱用戶是一組消費者而不是單個的進程。

在Kafka中實現消費的方式是將日誌中的分區劃分成多個消費者實例，因此，每個實例都是在任何時間點上“公平分享”分區的唯一的消費者。

團體中維護資格的進程由Kafka協議自由控制的。如果一個新的實例加入這個團體，他們將從其他團體成員中接管一些分區；如果一個實例死了，它的分區將被分配給其他剩余的實例。

Kafka只在一個分區內提供記錄的一個完整順序，而不是在一個topic內的不同分區之間。對於大多數應用程序來說，每個分區排序和按主鍵分區數據的能力都是足夠的。但是，如果你需要所有的記錄的一個完整的順序，這可以通過一個只有一個分區的topic實現，盡管這個將意味著每個消費者團體只有一個消費進程。

保障

一個高級別的Kafka將提供一下保障：

l 消息從一個生產者發送給一個特定的主題分區時將會附加上他們被發送的順序。也就是說，如果一條記錄M1和M2是有同一個生產者發送出去的，並且M1是先發送出去的，則M1的偏移量將會比M2的低，並且出現在log裏更早。

l 一個消費者實例將按他們在log中存儲的順序來理解這些記錄。

l 對於一個具有備份元素N的topic，我們將容忍N-1服務器故障，而不會丟失任何記錄到日誌中的記錄。

More details on these guarantees are given in the design section of the documentation.

.2.4 Kafka作為一個消息系統

Kafka消息系統與傳統企業消息系統的對比。

傳統消息有兩種模型：隊列和發布-訂閱（ queuing and publish-subscribe.）。

在對列中，一池的消費者將從一個服務上選讀，並且每條記錄都會被其中的一個消費者讀到；在發布-訂閱中，記錄將被廣播到所有的消費者。這兩種模型都有其優勢和劣勢。序列的優勢是它允許將數據處理進程分配給多個消費者實例，這樣可以讓你擴展你的進程。不幸的是，序列不是多用戶的，一旦一個進程讀取數據，數據就會消失。發布-訂閱，允許你廣播數據到多個進程，但是由於每條消失數據去了每個訂閱者，因此沒有辦法擴展進程。

Kafka中消費者團體的概念概括了這兩個概念。與隊列一樣，消費者組允許您通過一系列進程（消費者組的成員）來劃分處理。與發布訂閱一樣，Kafka允許您將消息廣播到多個消費者組。

Kafka模型的優點是，每個主題都具有這兩個屬性 - 它可以擴展處理，也是多用戶 - 不需要選擇一個或另一個。

Kafka也比傳統的消息系統有更強的順序保證。

“

傳統隊列在服務器上保存順序的記錄，如果多個消費者從隊列中消費，則服務器按照存儲順序輸出記錄。然而，雖然服務器按順序輸出記錄，但是記錄被異步傳遞給消費者，所以它們可能會在不同的消費者處按順序到達。這意味著在並行消耗的情況下，記錄的排序丟失。消息傳遞系統通常通過使“唯一消費者”的概念只能讓一個進程從隊列中消費，但這當然意味著處理中沒有並行性。

卡夫卡做得更好 通過在主題中有一個並行概念（分區），Kafka能夠在消費者流程池中提供排序保證和負載平衡。這通過將主題中的分區分配給消費者組中的消費者來實現，使得每個分區被組中的一個消費者消耗。通過這樣做，我們確保消費者是該分區的唯一讀者，並按順序消耗數據。由於有許多分區，這仍然平衡了許多消費者實例的負載。但請註意，消費者組中的消費者實例不能超過分區。

.2.5 卡夫卡作為存儲系統

允許發布消息消除消息的消息隊列有效地充當飛行中消息的存儲系統。卡夫卡的不同之處在於它是一個很好的存儲系統。

寫入Kafka的數據寫入磁盤並進行復制以進行容錯。Kafka允許生產者等待確認，以便在完全復制之前寫入不被認為是完整的，並且即使寫入服務器失敗，也保證持久寫入。

Kafka的磁盤結構使用縮放，Kafka將執行相同的操作，無論您在服務器上是否有50 KB或50 TB的持久數據。

作為嚴重存儲並允許客戶端控制其讀取位置的結果，您可以將Kafka視為專用於高性能，低延遲的提交日誌存儲，復制和傳播的專用分布式文件系統。

.2.6 Kafka流處理

僅讀取，寫入和存儲數據流是不夠的，目的是實現流的實時處理。

在卡夫卡，流處理器是從輸入主題接收數據流的任何東西，對此輸入執行一些處理，並生成持續的數據流以輸出主題。

例如，零售應用程序可能會收到銷售和出貨的輸入流，並輸出根據該數據計算的重新排序和價格調整。

可以直接使用生產者和消費者API進行簡單處理。然而對於更復雜的轉換，Kafka提供了一個完全集成的Streams API。這允許構建應用程序進行非平凡處理，以計算流中的聚合或將流連接在一起。

該設施有助於解決這種類型的應用程序面臨的困難問題：處理無序數據，重新處理輸入作為代碼更改，執行有狀態計算等。

流API基於Kafka提供的核心原語構建：它使用生產者和消費者API進行輸入，使用Kafka進行有狀態存儲，並在流處理器實例之間使用相同的組機制來實現容錯。

.2.7 放在一起

消息，存儲和流處理的這種組合似乎是不尋常的，但是卡夫卡作為流媒體平臺的角色至關重要。

像HDFS這樣的分布式文件系統允許存儲用於批處理的靜態文件。有效像這樣的系統允許存儲和處理歷史從過去的數據。

傳統的企業郵件系統允許處理將在您訂閱之後到達的未來郵件。以這種方式構建的應用程序在未來數據到達時處理。

Kafka結合了這兩種功能，組合對於Kafka作為流應用程序和流數據管道平臺來說至關重要。通過組合存儲和低延遲訂閱，流式應用程序可以以相同的方式處理過去和未來的數據。這是一個單一的應用程序可以處理歷史記錄數據，而不是在到達最後一個記錄時結束，它可以隨著將來的數據到達而繼續處理。這是一個廣泛的流處理概念，其中包含批處理以及消息驅動應用程序。

同樣，對於流數據流水線，訂閱到實時事件的組合使得可以使用Kafka進行非常低延遲的管道; 但是可靠性地存儲數據的能力使得可以將其用於必須保證數據傳送的關鍵數據，或者與僅負載數據的離線系統集成，或者可能會長時間停機以進行維護。流處理設備可以在數據到達時轉換數據。有關Kafka提供的保證，apis和功能的更多信息，請參閱其余的文檔。”

PS：本文完全參考“https://kafka.apache.org/”，即kafka官方主頁。

1、Kafka學習分享-V1.0