Kafka 文檔（介紹）

介紹

Apache Kafka®是一個分佈式流平臺，這究竟是什麼意思？

流平臺有三個關鍵功能：

• 發佈和訂閱記錄流，相似於消息隊列或企業消息傳遞系統
• 以容錯持久的方式存儲記錄流
• 在記錄流發生的時候處理它們

Kafka一般用於兩大類應用程序：

• 構建實時流數據管道，在系統或應用程序之間可靠地獲取數據
• 構建對數據流進行轉換或響應的實時流應用程序

要了解Kafka是如何完成這些事情的，讓咱們從底層深刻探究Kafka的能力。

第一步瞭解幾個概念：

• Kafka做爲集羣運行在一個或多個能夠跨多個數據中心的服務器上
• Kafka集羣以主題的類別存儲記錄流
• 每一個記錄由一個鍵、一個值和一個時間戳組成

Kafka有四個核心API：

• 生產者API容許應用程序將記錄流發佈到一個或多個Kafka主題
• 消費者API容許應用程序訂閱一個或多個主題並處理生產給它們的記錄流
• 流API容許應用程序充當流處理器，消費來自一個或多個主題的輸入流，並生產輸出流到一個或多個輸出主題，有效地將輸入流轉換爲輸出流。
• 鏈接器API容許構建和運行可重用的生產者或消費者，將Kafka主題與現有的應用程序或數據系統鏈接起來，例如，鏈接關係數據庫的鏈接器可能會捕獲對錶的全部更改。

在Kafka中，客戶機和服務器之間的通訊是使用簡單的、高性能的、與語言無關的TCP協議完成的，該協議是版本化的，並與舊版本保持向後兼容性，咱們爲Kafka提供一個Java客戶端，可是客戶端可使用多種語言。

主題和日誌

讓咱們首先深刻討論Kafka爲記錄流提供的核心抽象——主題。

主題是發佈記錄的類別或提要名稱，Kafka中的主題老是多訂閱者，也就是說，一個主題能夠有0個、1個或多個訂閱寫入到它的數據的消費者。

對於每一個主題，Kafka集羣維護一個相似於這樣的分區日誌：

每一個分區都是一個有序的、不可變的記錄序列，並不斷地附加到一個結構化的提交日誌中，分區中的記錄都被分配了一個名爲偏移量的連續id號，該偏移量唯一地標識分區中的每一個記錄。

Kafka集羣能夠持久地保存全部已發佈的記錄—不管它們是否被消費—並使用可配置的保留期。例如，若是保留策略被設置爲兩天，那麼在記錄發佈後的兩天內能夠消費它，而後將其丟棄以釋放空間，Kafka在數據大小方面的性能其實是恆定的，所以長時間存儲數據不是問題。

事實上，在每一個消費者的基礎上保留的惟一元數據是該消費者在日誌中的偏移量或位置，這個偏移量由消費者控制：一般消費者會在讀取記錄時線性地增長其偏移量，可是，實際上，因爲位置是由消費者控制的，它能夠按照本身喜歡的順序消費記錄。例如，消費者能夠重置到一個較早的偏移量來從新處理過去的數據，或者跳轉到最近的記錄並從「如今」開始消費。

這種特性的組合意味着Kafka消費者很是廉價——他們能夠來來去去，不會對集羣或其餘消費者形成太大影響。例如，你可使用咱們的命令行工具「跟蹤」任何主題的內容，而無需更改任何現有消費者消費的內容。

日誌中的分區提供有幾個用途。首先，它們容許日誌擴展到超出適合單個服務器的大小，每一個單獨的分區必須適合承載它的服務器，可是一個主題可能有許多分區，所以它能夠處理任意數量的數據，第二，它們做爲並行的單位——稍後再進一步探討。

分佈

日誌的分區分佈在Kafka集羣中的服務器上，每一個服務器處理數據和共享分區的請求，每一個分區在可配置的服務器數量上覆制，用於容錯。

每一個分區都有一個充當「leader」的服務器和一個或多個充當「followers」的服務器，leader處理分區的全部讀寫請求，而follower被動地複製leader，若是leader故障了，followers中的一個將自動成爲新的leader，每一個服務器做爲它的一些分區的leader，而做爲其餘分區的follower，因此集羣中的負載是很平衡的。

地理複製

Kafka MirrorMaker爲集羣提供地理複製支持，使用MirrorMaker，消息能夠跨多個數據中心或雲區域複製，你能夠在主動/被動場景中使用它進行備份和恢復，或者在活動/活動場景中，將數據放置到離用戶更近的位置，或者支持數據局部性需求。

生產者

生產者將數據發佈到他們選擇的主題，生成器負責選擇要將哪一個記錄分配給主題中的哪一個分區，這能夠以循環方式完成，只是爲了平衡負載，也能夠根據一些語義分區函數（好比基於記錄中的某個鍵）完成，使用分區的更多信息參見第二章！

消費者

消費者用消費者組名稱來標記本身，而且將發佈到主題的每一個記錄都被傳遞到每一個訂閱消費者組中的一個消費者實例，使用者實例能夠在單獨的進程中，也能夠在單獨的機器上。

若是全部消費者實例都有相同的消費者組，那麼記錄將有效地在消費者實例上進行負載均衡。

若是全部消費者實例都有不一樣的消費者組，那麼每一個記錄將被廣播到全部消費者進程。

一個負載四個分區(P0-P3)和兩個消費者組的兩個Kafka集羣服務器，消費者組A有兩個消費者實例，而B組有四個。

然而，更常見的是，咱們發現主題有少許的消費者組，每一個「邏輯訂閱者」對應一個消費者組，每一個組都由許多消費者實例組成，以實現可擴展性和容錯，這只不過是發佈-訂閱語義，其中訂閱服務器是一個消費者集羣，而不是一個進程。

在Kafka中實現消費的方式是在消費者實例中劃分日誌中的分區，以便每一個實例在任什麼時候候都是「公平共享」分區的惟一消費者，維持組中成員資格的過程是由Kafka協議動態處理的，若是新實例加入組，它們將從組的其餘成員接管一些分區，若是一個實例消亡，那麼它的分區將被分配給其餘實例。

Kafka只對一個分區內的記錄提供總的順序，而不是在主題中的不一樣分區之間，對大多數應用程序來講，每一個分區排序結合按鍵對數據進行分區的能力就足夠了，可是，若是你須要記錄上的總順序，這能夠經過只有一個分區的主題實現，儘管這意味着每一個消費者組只有一個消費者進程。

多租戶

你能夠將Kafka部署爲多租戶解決方案，經過配置哪一個主題能夠生產或消費數據來啓用多租戶，也有對配額的操做支持。管理員能夠對請求定義和強制配額，以控制客戶端使用的代理資源，有關更多信息，請參見安全文檔。

保證

在高級Kafka中提供如下保證：

• 生產者發送給特定主題分區的消息將按照發送的順序附加，也就是說，若是一個記錄M1是由與記錄M2相同的生產者發送的，而M1是先發送的，那麼M1的偏移量將小於M2，並出如今日誌的前面。
• 一個消費者實例會根據存儲在日誌中的順序來查看記錄。
• 對於複製因子N的主題，咱們能夠容忍最多N-1個服務器失敗，而不會丟失提交給日誌的任何記錄。

有關這些保證的更多細節將在文檔的設計部分中給出。

Kafka做爲一個消息系統

Kafka的流概念與傳統的企業消息傳遞系統相好比何?

消息傳遞傳統上有兩種模式：隊列和發佈-訂閱。在隊列中，消費者池能夠從服務器讀取數據，每一個記錄都將被髮送到其中一個，在發佈-訂閱中，記錄被廣播給全部的消費者，這兩種模式都有優勢和缺點。隊列的優點在於，它容許你在多個消費者實例上劃分數據處理，從而使你可以擴展處理，不幸的是，隊列不是多訂閱的—一旦一個進程讀取了數據，數據將消失。發佈-訂閱容許你向多個進程廣播數據，可是因爲每一個消息都傳遞給每一個訂閱服務器，所以沒有擴展處理的方法。

Kafka中的消費者組概念歸納了這兩個概念，與隊列同樣，消費者組容許你將處理劃分爲多個進程集合（消費者組的成員），與發佈訂閱同樣，Kafka容許你向多個消費者組廣播消息。

Kafka模型的優勢是每一個主題都具備這兩種特性——它能夠擴展處理而且也是多訂閱——不須要選擇其中之一或另外一個。

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

傳統隊列在服務器上保留記錄的順序，若是多個消費者從隊列中消費，那麼服務器按存儲記錄的順序分發記錄，然而，儘管服務器按順序分發記錄，但記錄是異步交付給消費者的，所以它們可能在不一樣的消費者上以無序的方式到達，這實際上意味着記錄的順序會在並行使用時丟失。消息傳遞系統一般是經過「獨佔消費者」的概念來工做的，它只容許一個進程從隊列中消費，但這固然意味着在處理過程當中沒有並行性。

Kafka是更好的，經過將並行性的概念劃分爲主題內的分區，Kafka可以在消費者進程池中同時提供順序保證和負載平衡。這是經過將主題中的分區分配給消費者組中的消費者來實現的，這樣每一個分區都由組中的一個消費者使用，經過這樣作，咱們確保消費者是該分區的惟一讀取者，並按順序消費數據，因爲有許多分區，這仍然平衡了許多消費者實例的負載，可是請注意，消費者組中的消費者實例不能超過度區。

Kafka做爲一個存儲系統

任何容許發佈消息與消費消息分離的消息隊列都有效地充當了正在運行的消息的存儲系統，Kafka的不一樣之處在於它是一個很是好的存儲系統。

寫入Kafka的數據被寫入磁盤並複製以得到容錯，Kafka容許生產者等待確認，直到徹底複製並保證即便被寫入的服務器發生故障也能保證寫入，才認爲寫入是完整的。

Kafka將磁盤結構使用的很好—不管你在服務器上有50KB或50TB的持久性數據，Kafka都將執行相同的操做。

因爲認真對待存儲，並容許客戶端控制其讀取位置，你能夠將Kafka視爲一種專用於高性能、低延遲提交日誌存儲、複製和傳播的分佈式文件系統。

有關Kafka的提交日誌存儲和複製設計的詳細信息，請閱讀設計章節。

Kafka的流處理

僅僅讀取、寫入和存儲數據流是不夠的，其目的是使流的實時處理成爲可能。

在Kafka中，流處理器能夠從輸入主題中獲取連續的數據流，對這個輸入執行一些處理，並生成連續的數據流到輸出主題。

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

能夠直接使用生產者和消費者API進行簡單的處理，然而，對於更復雜的轉換，Kafka提供一個完整的流API，這容許構建應用程序，這些應用程序進行不是通常的處理，從流中計算聚合或將流鏈接到一塊兒。

該工具備助於解決此類應用程序面臨的難題：處理無序數據，從新處理輸入做爲代碼變動，執行有狀態計算等。

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

把碎片拼在一塊兒

這種消息傳遞、存儲和流處理的組合看起來可能不太常見，但對於Kafka做爲流平臺的角色來講是很是重要的。

像HDFS這樣的分佈式文件系統容許爲批處理存儲靜態文件，這樣的系統能夠有效地存儲和處理過去的歷史數據。

傳統的企業消息傳遞系統容許處理訂閱後將到達的將來消息，以這種方式構建的應用程序在數據到達時處理它們。

Kafka將這兩種功能結合起來，對於Kafka做爲流應用程序的平臺以及流數據管道來講，這種組合很是關鍵。

經過結合存儲和低延遲訂閱，流應用程序能夠以相同的方式處理過去和將來的數據，這是一個單一的應用程序能夠處理歷史的、存儲的數據，可是當它到達最後一個記錄時，它能夠繼續處理，由於未來的數據會到達，這是流處理的廣義概念，它包括批處理和消息驅動應用程序。

一樣，對於流數據管道，對實時事件的訂閱組合使得能夠將Kafka用於很是低延遲的管道；可是，可以可靠地存儲數據的能力使其可以在必須保證數據交付的關鍵數據中使用它或者與只按期裝載數據的脫機系統集成，或者可能在較長時間內進行維護，流處理工具使數據在到達時進行轉換成爲可能。

有關Kafka提供的保證、api和功能的更多信息，請參見其他文檔。