Apache Kafka™ 是 一個分布式數據流平台. 這意味什麼呢?

我們認為一個數據流平台有三種能力:

1. 它讓你發布和訂閱數據流. 在這方麵他與消息隊列或企業級消息係統很像.
2. 它讓你具有很強容災性的存儲數據流.
3. 它讓你及時的處理數據流.

那麼Kafka適合做什麼呢? 它通常被使用在兩大類應用中:

1. 搭建可以使數據在係統或應用之間流動的實時數據流管道（pipelines）
2. 搭建可以針對流數據實行實時轉換或作出相應反應的數據流應用

為了了解Kafka具體如何實現這些功能, 我們來從底層開始，探索一下Kafka的功能。 首先講幾個概念:

• Kafka是作為集群，運行在一台或多台服務器上的.
• Kafka集群用主題（topics）來分類別儲存數據流（records）.
• 每個記錄（record）由一個鍵（key），一個值（value）和一個時間戳（timestamp）組成

Kafka有4個核心APIs:

Kafka的客戶端和服務器之間的通信是用一種簡單，高性能,語言獨立的TCP協議實現的. 此協議是版本化的並保持與舊版本的向後兼容性. 我們為Kafka提供了一個Java客戶端, 但也支持很多其他語言的客戶端.

主題（Topics）與日誌（Logs）

作為Kafka對數據提供的核心抽象，我們先來深度探究一下主題（topic）這個概念 主題是發布的數據流的類別或名稱。主題在Kafka中，總是支持多訂閱者的; 也就是說，主題可以有零個，一個或多個消費者訂閱寫到相應主題的數據. 對應每一個主題，Kafka集群會維護像一個如下這樣的分區的日誌:每個分區都是是一個有序的，不可變的，並且不斷被附加的記錄序列，—也就是一個結構化提交日誌（commit log）.為了保證唯一標性識分區中的每個數據記錄，分區中的記錄每個都會被分配一個一個叫做偏移（offset）順序的ID號. 通過一個可配置的保留期，Kafka集群會保留所有被發布的數據，不管它們是不是已經被消費者處理. 例如，如果保留期設置為兩天，則在發布記錄後的兩天內，數據都可以被消費，之後它將被丟棄以釋放空間。 卡夫卡的性能是不為因為數據量大小而受影響的，因此長時間存儲數據並不成問題。事實上，在每個消費者上保留的唯一元數據是消費者在日誌中的偏移位置。這個偏移由消費者控製：通常消費者會在讀取記錄時線性地提高其偏移值（offset++），但實際上，由於偏移位置由消費者控製，它可以以任何順序來處理數據記錄。 例如，消費者可以重置為較舊的偏移量以重新處理來自過去的數據，或者跳過之前的記錄，並從“現在”開始消費。 這種特征的組合意味著卡夫卡消費者非常輕量級 — 隨意的開啟和關閉並不會對其他的消費者有大的影響。例如，您可以使用我們的命令行工具tail來查看任何主題的內容，而無需更改任何現有消費者所消耗的內容。 日誌中的分區有幾個目的。 首先，它保證日誌的擴展性，主題的大小不受單個服務器大小的限製。每個單獨的分區大小必須小於托管它的服務器磁盤大小，但主題可能有很多分區，因此它可以處理任意數量的海量數據。第二，它可以作為並行處理的單位 — 這個我們等下再多談.

數據的分配（Distribution）

在Kafka集群中，不同分區日誌的分布在相應的不同的服務器節點上，每個服務器節點處理自己分區對應的數據和請求。每個分區都會被複製備份到幾個（可配置）服務器節點，以實現容錯容災。 分布在不同節點的同一個分區都會有一個服務器節點作為領導者（”leader”）和0個或者多個跟隨者（”followers”）. 分區的領導者會處理所有的讀和寫請求，而跟隨者隻會被動的複製領導者.如果leader掛了, 一個follower會自動變成leader。每個服務器都會作為其一些分區的領導者，但同時也可能作為其他分分區的跟隨者，Kafka以此來實現在集群內的負載平衡。

生產者

生產者將數據發布到他們選擇的主題。 生產者負責選擇要吧數據分配給主題中哪個分區。這可以通過循環方式（round-robin）簡單地平衡負載，或者可以根據某些語義分區（例如基於數據中的某些關鍵字）來完成。我們等一下就來討論分區的使用！

消費者

消費者們使用消費群組名稱來標注自己，幾個消費者共享一個組群名，每一個發布到主題的數據會被傳遞到每個消費者群組中的一個消費者實例。 消費者實例可以在不同的進程中或不同的機器上。 如果所有的消費者實例具有相同的消費者組，則記錄將在所有的消費者實例上有效地負載平衡,每個數據隻發到了一個消費者 如果所有的消費者實例都有不同的消費者群體，那麼每個記錄將被廣播給所有的消費者進程，每個數據都發到了所有的消費者。如上圖，一個兩個服務器節點的Kafka集群， 托管著4個分區(P0-P3)，分為兩個消費者群. 消費者群A有2個消費者實例，消費者群B有4個. 然而，更常見的是，我們發現主題具有少量的消費者群，每個消費者群代表一個“邏輯訂戶”。每個組由許多消費者實例組成，保證可擴展性和容錯能力。這可以說是“發布-訂閱”語義，但用戶是一組消費者而不是單個進程。 在Kafka中實現消費的方式，是通過將日誌中的分區均分到消費者實例上，以便每個實例在任何時間都是“相應大小的一塊”分區的唯一消費者。維護消費者組成員資格的過程，由卡夫卡協議動態處理。 如果新的實例加入組，他們將從組中的其他成員接管一些分區; 如果一個實例消失，其分區將被分發到剩餘的實例。 Kafka僅提供單個分區內的記錄的順序，而不是主題中的不同分區之間的總順序。 每個分區排序結合按鍵分區，足以滿足大多數應用程序的需求。 但是，如果您需要使用總順序，則可以通過僅具有一個分區的主題來實現，盡管這僅意味著每個消費者組隻有一個消費者進程。

保證

在高可用的Kafka集群中，我們有如下的保證:

• 生產者發送到特定主題分區的消息將按照發送的順序進行追加。 也就是說，如果記錄M1由與記錄M2相同的製造者發送，並且首先發送M1，則M1將具有比M2更低的偏移並且在日誌中較早出現。
• 消費者實例觀察到數據的順序，與它們存儲在日誌中的順序一致。
• 對於具有複製因子N的主題，我們將容忍最多N-1個服務器故障，而不會丟失提交到日誌的任何記錄。

更多有關這些“保證”的細節會在有關設計的文檔中。

Kafka作為消息係統

Kafka的數據流概念與傳統的企業消息係統相比如何？ 消息係統傳統上有兩種模式: 隊列和發布-訂閱. 在隊列中，消費者池可以從服務器讀取，每條記錄都轉到其中一個; 在發布訂閱中，記錄將廣播給所有消費者。 這兩個模型中的每一個都有優點和缺點。 排隊的優點是它允許您在多個消費者實例上分配數據處理，從而可以擴展您的處理。 不幸的是，隊列支持多用戶，一旦一個進程讀取數據就沒有了。 發布訂閱允許您將數據廣播到多個進程，但無法縮放和擴容，因為每個消息都發送給每個訂閱用戶。 卡夫卡消費群體概念概括了這兩個概念。 與隊列一樣，消費者組允許您通過一係列進程（消費者組的成員）來劃分處理。 與發布訂閱一樣，Kafka允許您將消息廣播到多個消費者組。 Kafka模型的優點是，每個主題都具有這兩個屬性，它可以進行縮放處理，也是多用戶的，沒有必要選擇一個而放棄另一個。 卡夫卡也比傳統的消息係統有更強大的消息次序保證。 傳統隊列在服務器上保存順序的記錄，如果多個消費者從隊列中消費，則服務器按照存儲順序輸出記錄。 然而，雖然服務器按順序輸出記錄，但是記錄被異步傳遞給消費者，所以它們可能會在不同的消費者處按不確定的順序到達。 這意味著在並行消耗的情況下，記錄的排序丟失。 消息傳遞係統通常通過使“唯一消費者”的概念隻能讓一個進程從隊列中消費，但這當然意味著處理中沒有並行性。 卡夫卡做得更好。通過分區，在一個主題之內的並行處理，Kafka能夠在消費者流程池中，即提供排序保證，也負載平衡。這是通過將主題中的分區分配給消費者組中的消費者來實現的，以便每一個分區由組中的一個消費者使用。 通過這樣做，我們確保消費者是該分區的唯一讀者，並按順序消耗數據。 由於有許多分區，這仍然平衡了許多消費者實例的負載。 但是請注意，消費者組中的消費者實例個數不能超過分區的個數。

Kafka作為存儲係統

任何允許發布消息，解耦使用消息的消息隊列，都在本質上充當傳輸中途消息的存儲係統。 卡夫卡的不同之處在於它是一個很好的存儲係統。 寫入Kafka的數據寫入磁盤並進行複製以進行容錯。 Kafka允許生產者等待寫入完成的確認，這樣在數據完全複製之前，寫入是未完成的，並且即使寫入服務器失敗，也保證持久寫入。 Kafka的磁盤結構使用可以很好的擴容，無論您在服務器上是否有50KB或50TB的持久數據，Kafka都能保持穩定的性能。 由於對存儲花費了很多精力，並允許客戶端控製其讀取位置，您可以將Kafka視為，專用於高性能，低延遲的日誌存儲複製和傳播的專用分布式文件係統。

Kafka用於流數據處理

僅讀取，寫入和存儲數據流是不夠的，Kafka的目的是實現流的實時處理。 在Kafka中，流處理器的定義是：任何從輸入主題接收數據流，對此輸入執行一些處理，並生成持續的數據流道輸出主題的組件。 例如，零售應用程序可能會收到銷售和出貨的輸入流，並輸出根據該數據計算的重新排序和價格調整的輸出流。 當然我們也可以直接用producer and consumer APIs在做簡單的出列. 然而對於更複雜的轉換，Kafka提供了一個完全集成的Streams API。這允許我們構建應用程序進行更複雜的運算，或者聚合，或將流連接在一起。 該設施有助於解決這種類型的應用程序麵臨的困難問題：處理無序數據，重新處理輸入作為代碼更改，執行有狀態計算等。 Stream API基於Kafka提供的核心原語構建：它使用生產者和消費者API進行輸入，使用Kafka進行有狀態存儲，並在流處理器實例之間使用相同的組機製來實現容錯。

放在一起，綜上所述

消息係統，數據存儲和流處理的這種組合似乎是不尋常的，但是這些特性對於Kafka作為流媒體平台的角色至關重要。 像HDFS這樣的分布式文件係統允許存儲用於批處理的靜態文件。 本質上，這樣的係統允許存儲和處理來自過去的曆史數據。 傳統的企業郵消息係統允許處理將在您訂閱之後到達的未來消息。 以這種方式構建的應用程序在未來數據到達時即使處理。 Kafka結合了這兩種功能，這種組合對於Kafka作為流應用程序和流數據管道平台來說至關重要。 通過組合存儲和低延遲訂閱，流式應用程序可以以相同的方式處理過去和未來的數據。 這是一個單一的應用程序可以處理曆史記錄數據，而不是在到達最後一個記錄時結束，它可以隨著將來的數據到達而繼續處理。 這是一個廣泛的流處理概念，其中包含批處理以及消息驅動應用程序。 同樣，對於流數據流水線，訂閱到實時事件的組合使得可以使用Kafka進行非常低延遲的管道傳輸; 可靠地存儲數據的能力使得可以將其用於必須保證數據傳送的關鍵數據，或者與僅負載數據的離線係統集成，或者可能會長時間停機以進行維護。 流處理設備可以在數據到達時轉換數據 有關Kafka提供的保證，apis和功能的更多信息，請參閱其餘部分documentation.

轉載自 並發編程網 - ifeve.com