Kafka架構
- Kafka概念和基本架構
-
- Kafka介紹
- Kafka優勢
- Kafka應用場景
- 基本架構
-
- 消息和批次
- 模式
- 主題和分區
- 生産者和消費者
- broker和叢集
- 核心概念
-
- Producer
- Consumer
- Broker
- Topic
- Partition
- Replicas
- Offset
- 副本
- 總結
Kafka概念和基本架構
Kafka介紹
Kafka是最初由Linkedin公司開發,是一個分布式、分區的、多副本的、多生産者、多訂閱者,基于zookeeper協調的分布式日志系統(也可以當做MQ系統),常見可以用于web/nginx日志、通路日志,消息服務等等,Linkedin于2010年獻給了Apache基金會并成為頂級開源項目。
主要應用場景是:日志收集系統和消息系統。
Kafka主要設計目标如下:
- 以時間複雜度為O(1)的方式提供消息持久化能力,即使對TB級以上資料也能保證常數時間的通路性能。
- 高吞吐率。即使在非常廉價的商用機器上也能做到單機支援每秒100K條消息的傳輸。
- 支援Kafka Server間的消息分區,及分布式消費,同時保證每個partition内的消息順序傳輸。
- 同時支援離線資料處理和實時資料處理。
- 支援線上水準擴充
聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結 有兩種主要的消息傳遞模式:點對點傳遞模式、釋出-訂閱模式。大部分的消息系統選用釋出-訂閱模式。Kafka就是一種釋出-訂閱模式。
對于消息中間件,消息分推拉兩種模式。Kafka隻有消息的拉取,沒有推送,可以通過輪詢實作消息的推送。
- Kafka在一個或多個可以跨越多個資料中心的伺服器上作為叢集運作。
- Kafka叢集中按照主題分類管理,一個主題可以有多個分區,一個分區可以有多個副本分區。
- 每個記錄由一個鍵,一個值和一個時間戳組成。
Kafka具有四個核心API:
- Producer API:允許應用程式将記錄流釋出到一個或多個Kafka主題。
- Consumer API:允許應用程式訂閱一個或多個主題并處理為其生成的記錄流。
- Streams API:允許應用程式充當流處理器,使用一個或多個主題的輸入流,并生成一個或多個輸出主題的輸出流,進而有效地将輸入流轉換為輸出流。
- Connector API:允許建構和運作将Kafka主題連接配接到現有應用程式或資料系統的可重用生産者或使用者。例如,關系資料庫的連接配接器可能會捕獲對表的所有更改。
Kafka優勢
- 高吞吐量:單機每秒處理幾十上百萬的消息量。即使存儲了許多TB的消息,它也保持穩定的性能。
- 高性能:單節點支援上千個用戶端,并保證零停機和零資料丢失。
- 持久化資料存儲:将消息持久化到磁盤。通過将資料持久化到硬碟以及replication防止資料丢失。
- 零拷貝
- 順序讀,順序寫
- 利用Linux的頁緩存
- 分布式系統,易于向外擴充。所有的Producer、Broker和Consumer都會有多個,均為分布式的。無需停機即可擴充機器。多個Producer、Consumer可能是不同的應用。
- 可靠性 - Kafka是分布式,分區,複制和容錯的。
- 用戶端狀态維護:消息被處理的狀态是在Consumer端維護,而不是由server端維護。當失敗時能自動平衡。
- 支援online和offline的場景。
- 支援多種用戶端語言。Kafka支援Java、.NET、PHP、Python等多種語言
Kafka應用場景
- 日志收集:一個公司可以用Kafka可以收集各種服務的Log,通過Kafka以統一接口服務的方式開放給各種Consumer;
- 消息系統:解耦生産者和消費者、緩存消息等;
- 使用者活動跟蹤:Kafka經常被用來記錄Web使用者或者App使用者的各種活動,如浏覽網頁、搜尋、點選等活動,這些活動資訊被各個伺服器釋出到Kafka的Topic中,然後消費者通過訂閱這些Topic來做實時的監控分析,亦可儲存到資料庫;
- 營運名額:Kafka也經常用來記錄營運監控資料。包括收集各種分布式應用的資料,生産各種操作的集中回報,比如報警和報告;
- 流式處理:比如Spark Streaming和Storm。
基本架構
消息和批次
Kafka的資料單元稱為消息。可以把消息看成是資料庫裡的一個“資料行”或一條“記錄”。消息由位元組數組組成。
消息有鍵,鍵也是一個位元組數組。當消息以一種可控的方式寫入不同的分區時,會用到鍵。
為了提高效率,消息被分批寫入Kafka。批次就是一組消息,這些消息屬于同一個主題和分區。
把消息分成批次可以減少網絡開銷。批次越大,機關時間内處理的消息就越多,單個消息的傳輸時間就越長。批次資料會被壓縮,這樣可以提升資料的傳輸和存儲能力,但是需要更多的計算處理。
模式
消息模式(schema)有許多可用的選項,以便于了解。如JSON和XML,但是它們缺乏強類型處理能力。Kafka的許多開發者喜歡使用Apache Avro。Avro提供了一種緊湊的序列化格式,模式和消息體分開。當模式發生變化時,不需要重新生成代碼,它還支援強類型和模式進化,其版本既向前相容,也向後相容。
資料格式的一緻性對Kafka很重要,因為它消除了消息讀寫操作之間的耦合性。
主題和分區
Kafka的消息通過主題進行分類。主題可比是資料庫的表或者檔案系統裡的檔案夾。主題可以被分為若幹分區,一個主題通過分區分布于Kafka叢集中,提供了橫向擴充的能力。
生産者和消費者
生産者建立消息。消費者消費消息。
一個消息被釋出到一個特定的主題上。
生産者在預設情況下把消息均衡地分布到主題的所有分區上:
- 直接指定消息的分區
- 根據消息的key散列取模得出分區
- 輪詢指定分區。
消費者通過偏移量來區分已經讀過的消息,進而消費消息。
消費者是消費組的一部分。消費組保證每個分區隻能被一個消費者使用,避免重複消費。
broker和叢集
一個獨立的Kafka伺服器稱為broker。broker接收來自生産者的消息,為消息設定偏移量,并送出消息到磁盤儲存。broker為消費者提供服務,對讀取分區的請求做出響應,傳回已經送出到磁盤上的消息。單個broker可以輕松處理數千個分區以及每秒百萬級的消息量。
每個叢集都有一個broker是叢集控制器(自動從叢集的活躍成員中選舉出來)。
控制器負責管理工作:
- 将分區配置設定給broker
- 監控broker
叢集中一個分區屬于一個broker,該broker稱為分區首領。
一個分區可以配置設定給多個broker,此時會發生分區複制。
分區的複制提供了消息備援,高可用。副本分區不負責處理消息的讀寫。
核心概念
Producer
生産者建立消息。
該角色将消息釋出到Kafka的topic中。broker接收到生産者發送的消息後,broker将該消息追加到目前用于追加資料的 segment 檔案中。
一般情況下,一個消息會被釋出到一個特定的主題上。
- 預設情況下通過輪詢把消息均衡地分布到主題的所有分區上。
- 在某些情況下,生産者會把消息直接寫到指定的分區。這通常是通過消息鍵和分區器來實作的,分區器為鍵生成一個散列值,并将其映射到指定的分區上。這樣可以保證包含同一個鍵的消息會被寫到同一個分區上。
- 生産者也可以使用自定義的分區器,根據不同的業務規則将消息映射到分區。
Consumer
消費者讀取消息。
- 消費者訂閱一個或多個主題,并按照消息生成的順序讀取它們。
- 消費者通過檢查消息的偏移量來區分已經讀取過的消息。偏移量是另一種中繼資料,它是一個不斷遞增的整數值,在建立消息時,Kafka 會把它添加到消息裡。在給定的分區裡,每個消息的偏移量都是唯一的。消費者把每個分區最後讀取的消息偏移量儲存在Zookeeper 或Kafka上,如果消費者關閉或重新開機,它的讀取狀态不會丢失。
- 消費者是消費組的一部分。群組保證每個分區隻能被一個消費者使用。
- 如果一個消費者失效,消費組裡的其他消費者可以接管失效消費者的工作,再平衡,分區重新配置設定。
Broker
一個獨立的Kafka 伺服器被稱為broker。
broker 為消費者提供服務,對讀取分區的請求作出響應,傳回已經送出到磁盤上的消息。
- 如果某topic有N個partition,叢集有N個broker,那麼每個broker存儲該topic的一個partition。
- 如果某topic有N個partition,叢集有(N+M)個broker,那麼其中有N個broker存儲該topic的一個partition,剩下的M個broker不存儲該topic的partition資料。
- 如果某topic有N個partition,叢集中broker數目少于N個,那麼一個broker存儲該topic的一個或多個partition。在實際生産環境中,盡量避免這種情況的發生,這種情況容易導緻Kafka叢集資料不均衡。
broker 是叢集的組成部分。每個叢集都有一個broker 同時充當了叢集控制器的角色(自動從叢集的活躍成員中選舉出來)。
控制器負責管理工作,包括将分區配置設定給broker 和監控broker。
在叢集中,一個分區從屬于一個broker,該broker 被稱為分區的首領。
Topic
每條釋出到Kafka叢集的消息都有一個類别,這個類别被稱為Topic。
實體上不同Topic的消息分開存儲。
主題就好比資料庫的表,尤其是分庫分表之後的邏輯表。
Partition
- 主題可以被分為若幹個分區,一個分區就是一個送出日志。
- 消息以追加的方式寫入分區,然後以先入先出的順序讀取。
- 無法在整個主題範圍内保證消息的順序,但可以保證消息在單個分區内的順序。
- Kafka 通過分區來實作資料備援和伸縮性。
- 在需要嚴格保證消息的消費順序的場景下,需要将partition數目設為1。
Replicas
Kafka 使用主題來組織資料,每個主題被分為若幹個分區,每個分區有多個副本。那些副本被儲存在broker 上,每個broker 可以儲存成百上千個屬于不同主題和分區的副本。
副本有以下兩種類型:
首領副本
每個分區都有一個首領副本。為了保證一緻性,所有生産者請求和消費者請求都會經過這個副本。
跟随者副本
首領以外的副本都是跟随者副本。跟随者副本不處理來自用戶端的請求,它們唯一的任務就是從首領那裡複制消息,保持與首領一緻的狀态。如果首領發生崩潰,其中的一個跟随者會被提升為新首領。
Offset
生産者Offset
消息寫入的時候,每一個分區都有一個offset,這個offset就是生産者的offset,同時也是這個分區的最新最大的offset。
有些時候沒有指定某一個分區的offset,這個工作kafka幫我們完成。
消費者Offset
這是某一個分區的offset情況,生産者寫入的offset是最新最大的值是12,而當Consumer A進行消費時,從0開始消費,一直消費到了9,消費者的offset就記錄在9,Consumer B就紀錄在了11。等下一次他們再來消費時,他們可以選擇接着上一次的位置消費,當然也可以選擇從頭消費,或者跳到最近的記錄并從“現在”開始消費。
副本
Kafka通過副本保證高可用。副本分為首領副本(Leader)和跟随者副本(Follower)。
跟随者副本包括同步副本和不同步副本,在發生首領副本切換的時候,隻有同步副本可以切換為首領副本。
AR
分區中的所有副本統稱為AR(Assigned Repllicas)。
AR=ISR+OSR
ISR
所有與leader副本保持一定程度同步的副本(包括Leader)組成ISR(In-Sync Replicas),ISR集合是AR集合中的一個子集。消息會先發送到leader副本,然後follower副本才能從leader副本中拉取消息進行同步,同步期間内follower副本相對于leader副本而言會有一定程度的滞後。前面所說的“一定程度”是指可以忍受的滞後範圍,這個範圍可以通過參數進行配置
OSR
與leader副本同步滞後過多的副本(不包括leader)副本,組成OSR(Out-Sync Relipcas)。在正常情況下,所有的follower副本都應該與leader副本保持一定程度的同步,即AR=ISR,OSR集合為空。
HW
HW是High Watermak的縮寫, 俗稱高水位,它表示了一個特定消息的偏移量(offset),消費者隻能拉取到這個offset之前的消息。
LEO
LEO是Log End Offset的縮寫,它表示了目前日志檔案中下一條待寫入消息的offset
總結
本節主要介紹了kafka的架構。