卡夫卡是一個分布式的流媒體平台##
流媒體平台有三個關鍵的功能:
-
發布和訂閱記錄流，類似於消息隊列或企業消息傳遞系統。
-
以容錯和持久的方式存儲記錄流
-
處理出現的記錄流
Kafaka通常應用於兩大類應用:
-
構建可以在系統或者應用程序之間可靠獲取數據的實時數據流管道
-
構建實時流應用程序，用於轉換或響應數據流
要了解卡夫卡如何做這些事情，讓我們深入探索卡夫卡的能力:
首先明確幾個概念:
-
Kafka作為一個集群運行在一台或多台可以跨越多個數據中心的服務器上。
-
卡夫卡集群在稱為主題的類別中存儲記錄流。
-
每條記錄由一個鍵，一個值和一個時間戳組成。
Kafka有四個核心的API:
-
Producer API允許應用程序將記錄流發布到一個或多個Kafka主題。
-
Consumer API允許應用程序訂閱一個或多個主題並處理為他們生成的記錄流。
-
Streams API允許應用程序充當流處理器，從一個或多個主題中消耗輸入流，並將輸出流生成為一個或多個輸出主題，從而將輸入流有效地轉換為輸出流。
-
連接器API允許構建和運行可重復使用的生產者或消費者，將Kafka主題連接到現有的應用程序或數據系統。例如，連接到關系數據庫的連接器可能會捕獲對表的每個更改。
在Kafka中，客戶端和服務器之間的通信是通過一種簡單的，高性能的，語言無關的TCP協議完成的。該協議是版本化的，新版本保持與舊版本的向后兼容性。我們為Kafka提供Java客戶端，但客戶端可以使用多種語言。
主題和日志
讓我們首先深入了解一下的核心抽象概念-- Topic
tipic是記錄發布到的類別或feed名稱。卡夫卡的topic始終是多用戶的;也就是說，一個主題可以有零個，一個或多個訂閱寫入數據的消費者。
對於每個主題，Kafka集群都維護一個分區日志，如下所示：
每個分區都是一個有序的，不可變的記錄序列，不斷追加到結構化的提交日志中。分區中的記錄每個分配一個連續的id號，稱為偏移量，用於唯一標識分區內的每條記錄。
Kafka集群使用可配置的保留期持續保留所有已發布的記錄 - 不管它們是否已被消費。例如，如果保留策略設置為兩天，則在記錄發布后的兩天內，它可用於消費，之后將被丟棄以釋放空間。卡夫卡的性能不會不會在數據量變大的時候變差，因此長時間存儲數據不成問題。
實際上，保留在每個消費者基礎上的唯一元數據是該消費者在日志中的偏移量或位置。這個偏移量是由消費者控制的：消費者通常會在讀取記錄時線性地推進其偏移量，但實際上，由於位置由消費者控制，因此它可以按照喜歡的任何順序消費記錄。例如，消費者可以重置為較舊的偏移量以重新處理來自過去的數據，或者跳至最近的記錄並從當前位置開始消費。
這種功能的組合意味着卡夫卡消費者非常輕量級 - 他們可以來來去去，對集群或其他消費者沒有太大影響。例如，您可以使用我們的命令行工具來“追查”任何主題的內容，而無需更改任何現有客戶使用的內容。
日志中的分區有多種用途。首先，它們允許日志的大小超出適合單個服務器的大小。每個單獨的分區必須適合承載它的服務器，但是一個topic可能有很多分區，因此它可以處理任意數量的數據。其次，它們作為並行的單位 - 更重要的是這一點。
分布式
日志的分區分布在Kafka集群中的服務器上，每個服務器處理數據並請求共享分區。每個分區都通過可配置數量的服務器進行復制以實現容錯。
每個分區都有一台服務器作為leader，零個或多個服務器作為followers。leader處理分區的所有讀取和寫入請求，而followers被動地復制leader。如果leader失敗，其中一個follower將自動成為新leader。每個服務器都充當其中一些分區的leader和其他人的followers，因此負載在集群內平衡良好。
區域復制
Kafka MirrorMaker為您的群集提供地理復制支持。借助MirrorMaker，消息可以跨多個數據中心或雲區域進行復制。您可以在主動/被動場景中將其用於備份和恢復;或者在主動/主動方案中將數據放置得更靠近用戶，或支持數據本地化要求。
Provider
生產者將數據發布到他們選擇的主題。生產者負責選擇將哪個記錄分配給主題中的哪個分區。這可以以循環方式完成，只是為了平衡負載，或者可以根據某種語義分區功能（例如基於記錄中的某個鍵）完成。更多關於在第二次使用分區！
consumer
消費者用消費者組名稱標記自己，並且發布到主題的每個記錄都被傳送到每個訂閱消費者組中的一個消費者實例。消費者實例可以在單獨的進程中或在單獨的機器上。
如果所有消費者實例具有相同的消費者組，則記錄將有效地在消費者實例上進行負載均衡。
如果所有消費者實例具有不同的消費者組，則每條記錄都將廣播給所有消費者進程。
兩個服務器Kafka集群托管四個分區（P0-P3）和兩個消費者組。消費者組A有兩個消費者實例，而組B有四個消費者實例。
然而，更常見的是，我們發現主圖的消費者群體很少，每個“邏輯用戶”都有一個。每個組由許多消費者實例組成，具有可擴展性和容錯性。這只不過是發布 - 訂閱語義，訂閱者是一群消費者而不是一個進程。
在Kafka中實現消費的方式是將日志中的分區分配給消費者實例，以便每個實例在任何時間點都是“公平分享”分區的獨占消費者。這個維護組中成員資格的過程是由Kafka協議動態處理的。如果新實例加入該組，則他們將接管來自該組的其他成員的一些分區;如果一個實例死亡，其分區將分配給其余實例。
卡夫卡只提供一個分區內記錄的總順序，而不是主題中不同分區之間的順序。按分區排序與按鍵分區數據的能力相結合，足以滿足大多數應用程序的需求。但是，如果您需要全部訂單而不是記錄，則可以通過僅有一個分區的主題來實現，但這意味着每個消費者組只有一個消費者進程。
多租戶
您可以將Kafka部署為多租戶解決方案。通過配置哪些主題可以產生或使用數據來啟用多租戶。還有配額操作支持。管理員可以根據請求定義和執行配額以控制客戶端使用的代理資源。有關更多信息，請參閱安全性文檔。
擔保
kafka提供了以下的高層次的保證:
-
由生產者發送到特定主題分區的消息將按照它們發送的順序附加。也就是說，如果記錄M1和M2由同一個生產者發送，並且M1被首先發送，則M1將具有比M2更低的偏移並且出現在日志中較早的地方。
-
消費者實例按照它們存儲在日志中的順序查看記錄。
-
對於具有復制因子N的主題，我們將容忍多達N-1個服務器故障，而不會丟失任何提交給日志的記錄。
有關這些保證的更多詳細信息在文檔的設計部分給出。
使用kafka作為消息系統
卡夫卡的流概念如何與傳統的企業消息傳遞系統進行對比？
消息傳統上有兩種模式：隊列和發布 - 訂閱。在隊列模式中，消費者池可以從服務器讀取，並且每條記錄都會轉到其中的一個;在發布 - 訂閱模式中記錄被廣播給所有消費者。這兩種模式都有優勢和劣勢。隊列的優勢在於它允許您將多個用戶實例中的數據處理分開，從而擴展您的處理。不幸的是，隊列不是多用戶的,一旦一個進程讀取之后,數據就消失了。發布 - 訂閱允許您將數據廣播到多個進程，但無法進行擴展處理，因為每條消息都發送給每個訂閱者。
卡夫卡的消費者組概念概括了這兩個概念。與隊列一樣，消費者組允許您划分一系列流程（消費者組的成員）的處理。與發布 - 訂閱一樣，卡夫卡允許您向多個消費者群體廣播消息。
卡夫卡的模型的優點是，每個主題都有兩個屬性，它可以擴展的處理，也是多用戶，有沒有必要選擇一個或另一個。
同時,Kafka也比傳統的消息系統有更強大的順序保障。
傳統隊列在服務器上按順序保留記錄，並且如果多個使用者從隊列中消耗，則服務器按照它們存儲的順序提交記錄。但是，盡管服務器按順序提交記錄，但記錄會異步傳送給消費者，因此它們可能會針對不同的消費者按順序到達。這實際上意味着在並行消耗的情況下記錄的排序會丟失。消息傳遞系統通常具有“排他消費者”的概念，只允許一個進程從隊列中消耗，但這當然意味着處理中沒有並行性。
卡夫卡做得更好。通過在主題內部有一個並行概念-分區概念，Kafka能夠在消費者流程池中提供順序保證和負載均衡。這是通過將主題中的分區分配給使用者組中的使用者來實現的，以便每個分區僅由組中的一位使用者使用。通過這樣做，我們確保消費者是該分區的唯一讀者，並按順序使用數據。由於有很多分區，這仍然可以平衡許多消費者實例的負載。但請注意，消費者組中的消費者實例不能多於分區。
使用kafka作為存儲系統
任何允許發布消息與消費消息分離的消息隊列都可以充當存儲系統的空中消息。卡夫卡的不同之處在於它是一個非常好的存儲系統。
寫入Kafka的數據寫入磁盤並進行復制以實現容錯。 Kafka允許生產者等待確認，以便寫入在完全復制之前不會被認為是完整的，並且即使寫入的服務器失敗也能保證持久化。
Kafka磁盤結構使用的規模很大 - 無論您在服務器上有50 KB還是50 TB的持久化數據，Kafka都會執行相同的操作。
作為認真考慮存儲並允許客戶端控制其讀取位置的結果，您可以將Kafka視為一種專用於高性能，低延遲提交日志存儲，復制和傳播的專用分布式文件系統。
有關Kafka提交日志存儲和復制設計的詳細信息，請閱讀本頁。
kafka的流處理:
僅讀取，寫入和存儲數據流是不夠的，目的是啟用流的實時處理。
在Kafka中，流處理器是指從輸入主題獲取連續數據流，對該輸入執行一些處理並生成連續數據流以輸出主題的任何內容。
例如，零售應用程序可能會接受銷售和裝運的輸入流，並輸出一系列重新排序和根據此數據計算出的價格調整。
可以直接使用生產者API和消費者API進行簡單的處理。然而，對於更復雜的轉換，Kafka提供完全集成的Streams API。這允許構建應用程序進行非平凡的處理，從而計算聚合關閉流或將流連接在一起。
這個工具有助於解決這類應用程序面臨的難題：處理無序數據，重新處理代碼更改的輸入，執行有狀態的計算等。
流API基於Kafka提供的核心原語構建：它使用生產者API和消費者API輸入，使用Kafka進行有狀態存儲，並在流處理器實例之間使用相同的組機制來實現容錯。
把碎片聚合起來
消息傳遞，存儲和流處理的這種組合可能看起來很不尋常，但對於Kafka作為流式傳輸平台的角色來說，這是非常重要的。
像HDFS這樣的分布式文件系統允許存儲用於批處理的靜態文件。這樣的系統允許存儲和處理過去的歷史數據。
傳統的企業消息傳遞系統允許處理訂閱后將會到來的消息。以這種方式構建的應用程序處理將來的數據。
Kafka結合了這兩種功能，而且這兩種組合對於Kafka用作流式傳輸應用平台和流式數據管道都非常重要。
通過將存儲和低延遲訂閱相結合，流式應用可以以相同的方式處理過去和未來的數據。這是一個單一的應用程序可以處理歷史的，存儲的數據，而不是在它達到最后一個記錄時結束，它可以在將來的數據到達時繼續處理。這是流處理的一般概念，包括批處理以及消息驅動的應用程序。
同樣，對於流式數據流水線，訂閱實時事件的組合使得可以將Kafka用於非常低延遲的流水線;但可靠地存儲數據的能力可以將其用於必須保證數據交付的關鍵數據，或者與只能定期加載數據的離線系統集成，或者可能在較長時間內停機進行維護。流處理設施可以在數據到達時進行轉換。
有關Kafka提供的擔保，API和功能的更多信息，請參閱其余文檔