Kafka組件體系結構是什么

本篇內容主要講解“Kafka組件體系結構是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kafka組件體系結構是什么”吧!

事件源，最終一致性，微服務，CQRS等等，這些越多越多的概念被現代開發者所熟悉。從細粒度的服務組裝到復雜的以業務為中心的應用架構，這其中最重要的一塊就是以中間件為基礎的業務脫藕。本文我們介紹中間件基礎構建塊——事務流。其主導者是Apache Kafka，事實上的事務流平臺標準，還會介紹Kafka的一個Web界面工具Kafdrop。

概述

事務流平臺屬于更廣泛的面向消息的中間件(MoM)類，與傳統的消息隊列和主題類似，但是由于日志結構的不變性，它提供了更強大的時間保證和大幅度性能提高。簡而言之，由于事務流的寫操作只限于順序追加，所以更加高效。

傳統消息隊列(MQ)中的消息往往是任意排序的，并且通常彼此獨立，而流中的事務(或記錄)往往是按時間順序或因果關系排序的。而且，事務流會保留其記錄，而MQ一旦讀取了一條消息，就會丟棄它。因此，事務流往往更適合事件驅動的體系結構，包括事件源，最終一致性和CQRS等(當然，也包括FIFO消息隊列，但是FIFO隊列和成熟的事務流平臺之間的差異非常大，而不僅限于訂購)。

事務流平臺是MoM領域中相對較新的范例。與數百種MQ風格的消息代理相比較，只有少數幾種主流可用。與已建立的標準(例如AMQP，MQTT，XMPP和JMS)相比，事務流空間中還沒有與之等效的標準。

事務流平臺是當前持續研究和實驗的活躍領域。但是，事務流平臺不僅僅是一個商用產品，或者復雜的學術問題。它可以廣泛應用于消息傳遞和事務場景，可用于例行性替換消息隊列的傳統使用場景。

架構概述

下圖簡要概述了Kafka組件體系結構。此處限于篇幅，我們不詳細介紹Kafka內部工作原理。

kafka組成

Kafka是一個分布式系統，包含如下幾個關鍵組件：

Broker(代理)節點：負責批量I/O操作和集群內的持續持久化。代理附加日志文件，這些文件中包含由集群托管的主題分區。可以在多個代理之間復制分區，以實現水平可伸縮性和增加的持久性，這些復制的分區被稱為副本。有一個代理節點為控制節點(控制者)，其他副本受其管理(追隨者)。一個代理節點會被選舉為集群控制器，負責分區狀態的內部管理，還負責仲裁給定分區的領導者跟隨者角色。

ZooKeeper節點：在后臺Kafka需要一種方法來管理集群中總體控制器狀態。如果控制器出于某種原因退出，則有一個協議可以從剩余的代理集中選出另一個控制器。ZooKeeper很大程度上實現了控制器選舉，心跳等的實際機制。ZooKeeper還充當各種配置存儲庫，維護集群元數據，領導者和跟隨者狀態，配額，用戶信息，ACL和其他內部管理項目。由于底層的選舉和共識協議，ZooKeeper節點的數量必須為奇數。

生產者：負責將消息發布到Kafka主題的客戶端應用程序。由于Kafka具有日志結構的性質，并且能夠在多消費者生態系統之間共享主題，因此只有生產者才能修改底層日志文件中的數據。實際I/O由代理節點代表生產者客戶端執行。可以將任意數量生產者消息發布到同一Kafka主題，并選擇用于保存記錄的分區。

消費者：從主題讀取消息的客戶端應用程序。任意數量的消費者都可以從同一主題中閱讀內容;但是，根據消費者的配置和分組，存在一些規則來管理消費者之間的記錄分配。

分區，記錄、偏移量和主題

分區是記錄的完全有序序列，每一個分區對應一個append日志，這是Kafka的基礎。每一條記錄具有一個ID：64位整數偏移量和毫秒級的時間簽。它可能會存在一個鍵和一個值。兩者都是字節數組，并且都是可選的。術語"完全排序"僅表示對于任何給定的生產者，記錄將按照應用程序發出的順序進行寫入。如果記錄P在Q之前發布，則P將在分區中的Q之前。(假設P和Q共享一個分區。)此外，所有消費者將以相同的順序讀取它們。對于每個可能的消費者，將始終在Q之前讀取P。在大多數用例中，這種訂購保證至關重要。通常，已發布的記錄將與某些現實事務相對應，并且保留這些事務的時間表通常是必不可少的。

記錄的偏移量是分區中一條記錄的唯一標識分。偏移量是稀疏地址空間中嚴格單調遞增的整數，每個記錄偏移量始終高于其上一個記錄偏移量，并且相鄰偏移量之間可能存在可變的間隙。如果啟用了壓縮或作為事務的結果，則必然會存在間隙，所以偏移量也有可能不是連續的。

應用程序不應嘗試從字面上解釋偏移量，也不應該猜測下一個偏移量是多少。但是，可以根據偏移量推斷任何記錄的相對順序，按記錄的偏移量對記錄進行排序。

下圖顯示了內部分區的結構：

第一個偏移量(也稱為low-water mark，低水位標記)是要顯示給消費者的第一個消息。由于Kafka的保留期限制，因此不一定是第一個發布的消息。可以根據時間和/或分區大小來修剪記錄。當有這種情況發生時，低水位線似乎會后移，早于低水位線的記錄將被截斷。

主題是分區的邏輯組成。一個主題可以具有一個或多個分區，而一個分區只能有一個主題或者一個主題的部分。主題是Kafka的基礎，允許并行和負載平衡。前面我們說過分區顯示總順序。由于主題內的分區是相互獨立的，因此稱該主題具有部分順序。簡而言之，這意味著某些記錄可以互相排序，而相對于某些其他記錄則不可排序。總順序和部分順序的概念雖然聽起來有些學術化，但在構建性能事務流管道中非常重要。它使我們能夠在可能的地方并行處理記錄，同時在必須的地方保持順序。稍后，我們將探討記錄順序，消費者并行性和主題大小的概念。

實例：消息發布

實踐是檢驗真理的唯一標準，我將理論付諸實踐，通過實例說明概念。我們將啟動一對Docker容器，一個用Kafka容器，另一個為Kafdrop容器。我們使用Docker Compose方式啟用容器。

在選定目錄中創建一個docker-compose.yaml文件，內容如下：

為了方便起見，我們用obsidiandynamics/kafka鏡像，它會將Kafka和ZooKeeper巧妙地打包在一個鏡像中。然后通過docker-compose up啟動容器。啟動成功后，可以通過瀏覽器中訪問localhost:9000，就能看到Kafdrop登陸界面。

實例中是一個單代理集群，還沒有任何主題。我們可以使用Kafka的命令行工具創建一個主題并發布一些消息。我們可以使用docker exec工具對kafka容器進行操作方便地調用內置的CLI工具：

docker exec -it kafka-kafdrop_kafka_1 bash

上面的命令將讓我么進入容器的shell命令行界面。工具位于/opt/kafka/bin目錄中，cd進入該目錄：

創建一個名為streams-intro的主題，其中包含3個分區：

切換回Kafdrop界面，現在我們就能在列表中看到新主創建的主題。

接著，我們可以使用kafka-console-producer工具發布消息：

注意：kafka-topics使用--bootstrap-server參數來配置Kafka代理列表，而kafka-console-producer則使用--broker-list。

記錄由換行符分隔。鍵和值部分由冒號分隔，如key.separator屬性所指示。本例下，我們可以輸入下內容：

完成后，按CTRL + D鍵完成消息發布。然后切換回Kafdrop，然后單擊streams-intro主題。將看到該主題的概述以及基礎分區的詳細分類：

我們創建了一個包含三個分區的主題。然后，我們使用兩個唯一的鍵foo和bar發布了五條記錄。Kafka使用鍵將記錄映射到分區，這樣具有相同鍵的所有記錄將始終出現在同一分區上。很方便，也很重要，它可以使發布者指定準確的記錄順序。稍后，我們將更詳細地討論鍵哈希和分區分配。

查看分區表，分區#0的第一個和最后一個偏移分別為0和2。分區#2的值為零和3個，而分區#1的顯示為空白。在Kafdrop網絡用戶界面中單擊#0，會將會轉到主題查看器：

可以看到在bar鍵下發布的兩條記錄。注意，它們與foo記錄完全無關。

消費者和消費組

上面我們實例講了，聽過生產者發布消息，將記錄發送到流中。這些記錄被組織成井井有條的分區。Kafka的發布-訂閱拓撲遵循靈活的多到多模型，所以，可以有任意數量的生產者和消費者同時與流進行交互。根據實際的解決方案，流拓撲也可以一對多，多對一。下面我們講，如何消費這些記錄。

消費者是通過客戶端庫連接到Kafka集群的進程或線程。消費者通常(但不一定)是一個整體消費組的成員。該組由group.id屬性指定。消費組實際上是Kafka中的負載平衡機制，負責在組內的各個消費者實例之間大致平均地進行分區分配。當組中的第一個消費者訂閱該主題時，它將收到該主題中的所有分區。當第二個消費者隨后加入時，它將獲得大約一半的分區，從而減輕了第一個使用者的負擔。當消費者離開時(通過斷開連接或超時)，該過程將反向進行，其余的使用者將可用更多數量的分區。

因此，消費者消費某個主題中的記錄，從Kafka及其所屬的其他消費者分配的分區中提取了份額。就負載平衡而言，這應該非常簡單。但是，這里有一個關鍵點，使用記錄的行為并不能將其刪除。起初這似乎是矛盾的，特別是如果將消耗行為與消耗聯系起來。(如果有的話，應該將消費者稱為"閱讀者"。)一個簡單的事實是，消費者對主題及其分區絕對沒有任何影響。主題是僅追加，只能由生產者或Kafka本身(作為壓縮或清除的一部分)進行追加記錄。消費者的只讀操作是"便宜的"，因此，可以讓許多人在不增加集群負擔的情況下tail日志。這是事務流和傳統消息隊列之間的又一區別，這是至關重要的。

消費者在內部維護一個偏移量，該偏移量指向分區中的下一個記錄，從而在每次連續讀取時都增加偏移量。消費者首次訂閱主題時，可以選擇從主題的頭端或尾端開始。通過將auto.offset.reset屬性設置為latest, earliest 或者none，可以控制這個行為。在后一種情況下，如果消費者組不存在先前的偏移量，則將觸發異常。

消費者在本地保留其偏移狀態向量。由于不同消費組中的消費者不會互相干擾，因此可能有許多人同時閱讀同一主題。消費者按照自己的偏移讀取消息;緩慢的或積壓的消費者對其同組其他人也不會有影響。

為了說明這個概念，我們考慮一個包含兩個分區的主題為場景。兩個消費者組-A和B-訂閱了該主題。每個組具有三個實例，使用者被命名為A1，A2，A3，B1，B2和B3。下圖說明了兩組如何共享主題，以及消費者如何彼此獨立地瀏覽記錄。

仔細看上圖，會發現缺少某些東西。消費者A3和B1不在上圖中。這是因為Kafka保證分區只能分配給其消費組中的一個消費者。由于每個組中有三個消費者，但是只有兩個分區，因此一個消費者將保持空閑狀態，等待其所在組中的另一個消費者離開。以這種方式，消費組不僅是負載平衡機制，而且還是用于建立高性能管道而又不犧牲安全性的類似柵欄的排他性控制，特別是在要求只能由一個線程處理記錄的情況下或在任何給定時間進行處理。

消費組也用于確保可用性。通過定期從主題中提取記錄，消費者可以向集群隱式反饋集群為"健康"狀態，從而將租約擴展到其分區分配上。但是，如果消費者未能在允許的期限內再次閱讀，則將其視為有缺陷，并且將重新分配其分區，分配給該組中其余的"健康"消費者。該截止日期由max.poll.interval.ms在消費者客戶端屬性控制，默認情況下設置為五分鐘。

用交通系統來做個類比，主題就像是高速公路，分區就是車道。記錄就是等同于汽車，其乘客對應于記錄值。只要保持行車路線，幾輛車就可以安全地在同一條高速公路上行駛。共享相同線路的汽車按順序行駛，形成隊列。現在，假設每條車道通向一個匝道，將其流量轉移到某個位置。如果一個匝道堆積了，其他匝道可能仍能順暢流動。

Kafka正是利用這種機制確保端到端的吞吐量，輕松地實現每秒達到數百萬條記錄的QPS。創建主題時，可以選擇分區計數，通道數。分區在一個消費組中的各個消費者之間大致均勻地劃分，并確保不會將分區同時分配給兩個(或多個)消費者。

注意：創建后，可以通過增加分區數來調整主題的大小。但是，無法在不重新創建主題的情況下減少分區數。

記錄對應于事件、消息、命令或任何其他可流式傳輸的內容。記錄的精確劃分方式由生產者決定。生產者可以在發布記錄時顯式分配分區索引，盡管這種方法很少使用。正如我們在前面的示例中所做的那樣，一種更常見的方法是為記錄分配鍵。鍵對Kafka完全不透明，換句話說，Kafka不會去解釋key的內容，而是將其視為字節數組。使用一致的哈希技術對這些字節進行哈希處理以得出分區索引。

共享相同散列的記錄可以保證占據相同的分區。假設一個主題具有多個分區，則具有不同鍵的記錄可能最終會位于不同的分區中。但是，由于哈希鍵沖突，具有不同哈希值的記錄也可能最終會在同一分區中。

生產者無需關心記錄將映射到哪個特定分區，只要相關記錄最終在同一分區中并且保留其順序。同樣，消費者對也無需關心分配到那個分區，只要它們以與發布相同的順序接收記錄，并且其分區分配不會與組中的其他消費者重復。

案例：交易平臺

假設我們正在尋找上市股票的特定價格模式，并在確定特定模式后發出交易信號。有大量庫存，可以理解的是，希望將它們并行處理。但是，任何給定的股票代碼的時間序列必須在單個使用者上順序處理。

Kafka使這個用例以及其他類似用例幾乎不容易實現。我們將創建兩個主題：價格，用來存儲原始價格數據。訂單主題，用來保存任何由產生的訂單。我們可以多劃分一些分區，可以讓我們充分的并行操作。

我們可以在價格主題上發布每個價格的記錄，并用股票代碼作為鍵。Kafka的自動分區分配將確保每個股票代號由其組中的一個消費者處理。消費者實例可以自由擴展和擴展以匹配處理負載。消費者組應該有意義地命名，理想地反映消費應用程序的目的。比如trading-strategy.abc，它是一種名為" ABC"的虛擬交易策略。

消費者確定了價格模式后，就可以在訂單主題上發布另一條消息，訂單請求。我們將召集另一個消費組，訂單執行，負責讀取訂單并將其轉發給經紀人。

在這個簡單的示例中，我們創建了一個完全由事件驅動且高度可擴展的端到端交易管道，假設沒有其他瓶頸。我們可以在各個階段動態添加更多的處理節點，以應對需要增加的負載的情況。

假設您需要在通用數據源的驅動下同時運行的幾種交易策略。此外，交易策略將由不同的團隊制定;目的是盡可能地使這些實現脫鉤，從而使團隊能夠自主運作，甚至可以使用不同的編程語言和工具鏈以各自的節奏進行開發和部署。

Kafka靈活的多到多pub-sub體系結構將狀態消耗與廣播語義相結合。通過使用不同的消費群體，Kafka允許不同的應用程序共享輸入主題，并按自己的進度處理事件。第二種交易策略將需要一個專門的消費群體：trading-strategy.xyz，將其特定的業務邏輯應用于通用定價流，并將生成的訂單發布到相同的訂單主題。通過這種方式，Kafka能夠從易于重用和組合的離散元素構建模塊化事件處理管道。

到此，相信大家對“Kafka組件體系結構是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！