天天看點

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

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隻有消息的拉取,沒有推送,可以通過輪詢實作消息的推送。

  1. Kafka在一個或多個可以跨越多個資料中心的伺服器上作為叢集運作。
  2. Kafka叢集中按照主題分類管理,一個主題可以有多個分區,一個分區可以有多個副本分區。
  3. 每個記錄由一個鍵,一個值和一個時間戳組成。

Kafka具有四個核心API:

  1. Producer API:允許應用程式将記錄流釋出到一個或多個Kafka主題。
  2. Consumer API:允許應用程式訂閱一個或多個主題并處理為其生成的記錄流。
  3. Streams API:允許應用程式充當流處理器,使用一個或多個主題的輸入流,并生成一個或多個輸出主題的輸出流,進而有效地将輸入流轉換為輸出流。
  4. Connector API:允許建構和運作将Kafka主題連接配接到現有應用程式或資料系統的可重用生産者或使用者。例如,關系資料庫的連接配接器可能會捕獲對表的所有更改。

Kafka優勢

  1. 高吞吐量:單機每秒處理幾十上百萬的消息量。即使存儲了許多TB的消息,它也保持穩定的性能。
  2. 高性能:單節點支援上千個用戶端,并保證零停機和零資料丢失。
  3. 持久化資料存儲:将消息持久化到磁盤。通過将資料持久化到硬碟以及replication防止資料丢失。
  4. 零拷貝
  5. 順序讀,順序寫
  6. 利用Linux的頁緩存
  7. 分布式系統,易于向外擴充。所有的Producer、Broker和Consumer都會有多個,均為分布式的。無需停機即可擴充機器。多個Producer、Consumer可能是不同的應用。
  8. 可靠性 - Kafka是分布式,分區,複制和容錯的。
  9. 用戶端狀态維護:消息被處理的狀态是在Consumer端維護,而不是由server端維護。當失敗時能自動平衡。
  10. 支援online和offline的場景。
  11. 支援多種用戶端語言。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叢集中,提供了橫向擴充的能力。

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

生産者和消費者

生産者建立消息。消費者消費消息。

一個消息被釋出到一個特定的主題上。

生産者在預設情況下把消息均衡地分布到主題的所有分區上:

  1. 直接指定消息的分區
  2. 根據消息的key散列取模得出分區
  3. 輪詢指定分區。

消費者通過偏移量來區分已經讀過的消息,進而消費消息。

消費者是消費組的一部分。消費組保證每個分區隻能被一個消費者使用,避免重複消費。

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

broker和叢集

一個獨立的Kafka伺服器稱為broker。broker接收來自生産者的消息,為消息設定偏移量,并送出消息到磁盤儲存。broker為消費者提供服務,對讀取分區的請求做出響應,傳回已經送出到磁盤上的消息。單個broker可以輕松處理數千個分區以及每秒百萬級的消息量。

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

每個叢集都有一個broker是叢集控制器(自動從叢集的活躍成員中選舉出來)。

控制器負責管理工作:

  • 将分區配置設定給broker
  • 監控broker

叢集中一個分區屬于一個broker,該broker稱為分區首領。

一個分區可以配置設定給多個broker,此時會發生分區複制。

分區的複制提供了消息備援,高可用。副本分區不負責處理消息的讀寫。

核心概念

Producer

生産者建立消息。

該角色将消息釋出到Kafka的topic中。broker接收到生産者發送的消息後,broker将該消息追加到目前用于追加資料的 segment 檔案中。

一般情況下,一個消息會被釋出到一個特定的主題上。

  1. 預設情況下通過輪詢把消息均衡地分布到主題的所有分區上。
  2. 在某些情況下,生産者會把消息直接寫到指定的分區。這通常是通過消息鍵和分區器來實作的,分區器為鍵生成一個散列值,并将其映射到指定的分區上。這樣可以保證包含同一個鍵的消息會被寫到同一個分區上。
  3. 生産者也可以使用自定義的分區器,根據不同的業務規則将消息映射到分區。

Consumer

消費者讀取消息。

  1. 消費者訂閱一個或多個主題,并按照消息生成的順序讀取它們。
  2. 消費者通過檢查消息的偏移量來區分已經讀取過的消息。偏移量是另一種中繼資料,它是一個不斷遞增的整數值,在建立消息時,Kafka 會把它添加到消息裡。在給定的分區裡,每個消息的偏移量都是唯一的。消費者把每個分區最後讀取的消息偏移量儲存在Zookeeper 或Kafka上,如果消費者關閉或重新開機,它的讀取狀态不會丢失。
  3. 消費者是消費組的一部分。群組保證每個分區隻能被一個消費者使用。
  4. 如果一個消費者失效,消費組裡的其他消費者可以接管失效消費者的工作,再平衡,分區重新配置設定。

Broker

一個獨立的Kafka 伺服器被稱為broker。

broker 為消費者提供服務,對讀取分區的請求作出響應,傳回已經送出到磁盤上的消息。

  1. 如果某topic有N個partition,叢集有N個broker,那麼每個broker存儲該topic的一個partition。
  2. 如果某topic有N個partition,叢集有(N+M)個broker,那麼其中有N個broker存儲該topic的一個partition,剩下的M個broker不存儲該topic的partition資料。
  3. 如果某topic有N個partition,叢集中broker數目少于N個,那麼一個broker存儲該topic的一個或多個partition。在實際生産環境中,盡量避免這種情況的發生,這種情況容易導緻Kafka叢集資料不均衡。

broker 是叢集的組成部分。每個叢集都有一個broker 同時充當了叢集控制器的角色(自動從叢集的活躍成員中選舉出來)。

控制器負責管理工作,包括将分區配置設定給broker 和監控broker。

在叢集中,一個分區從屬于一個broker,該broker 被稱為分區的首領。

Topic

每條釋出到Kafka叢集的消息都有一個類别,這個類别被稱為Topic。

實體上不同Topic的消息分開存儲。

主題就好比資料庫的表,尤其是分庫分表之後的邏輯表。

Partition

  1. 主題可以被分為若幹個分區,一個分區就是一個送出日志。
  2. 消息以追加的方式寫入分區,然後以先入先出的順序讀取。
  3. 無法在整個主題範圍内保證消息的順序,但可以保證消息在單個分區内的順序。
  4. Kafka 通過分區來實作資料備援和伸縮性。
  5. 在需要嚴格保證消息的消費順序的場景下,需要将partition數目設為1。

Replicas

Kafka 使用主題來組織資料,每個主題被分為若幹個分區,每個分區有多個副本。那些副本被儲存在broker 上,每個broker 可以儲存成百上千個屬于不同主題和分區的副本。

副本有以下兩種類型:

首領副本

每個分區都有一個首領副本。為了保證一緻性,所有生産者請求和消費者請求都會經過這個副本。

跟随者副本

首領以外的副本都是跟随者副本。跟随者副本不處理來自用戶端的請求,它們唯一的任務就是從首領那裡複制消息,保持與首領一緻的狀态。如果首領發生崩潰,其中的一個跟随者會被提升為新首領。

Offset

生産者Offset

消息寫入的時候,每一個分區都有一個offset,這個offset就是生産者的offset,同時也是這個分區的最新最大的offset。

有些時候沒有指定某一個分區的offset,這個工作kafka幫我們完成。

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

消費者Offset

聊聊Kafka(一)Kafka架構Kafka概念和基本架構總結

這是某一個分區的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(一)Kafka架構Kafka概念和基本架構總結

總結

本節主要介紹了kafka的架構。