Kafka 一篇文章帶你快速搞定Kafka術語

Kafka 一篇文章帶你快速搞定Kafka術語

在 Kafka 的世界中有不少概念和術語是須要你提早理解並熟練掌握的,這對於後面你深刻學習 Kafka 各類功能和特性將大有裨益。服務器

下面我來盤點一下 Kafka 的各類術語。架構

基本邏輯

Kafka 屬於分佈式的消息引擎系統 。在 Kafka 中,發佈訂閱的對象是主題(Topic),你能夠爲每一個業務、每一個應用甚至是每類數據都建立專屬的主題。向主題發佈消息的客戶端應用程序稱爲生產者(Producer),生產者程序一般持續不斷地向一個或多個主題發送消息,而訂閱這些主題消息的客戶端應用程序就被稱爲消費者(Consumer)分佈式

和生產者相似,消費者也可以同時訂閱多個主題的消息。咱們把生產者和消費者統稱爲客戶端(Clients)。你能夠同時運行多個生產者和消費者實例,這些實例會不斷地向 Kafka 集羣中的多個主題生產和消費消息。性能

有客戶端天然也就有服務器端。Kafka 的服務器端由被稱爲 Broker 的服務進程構成,即一個 Kafka 集羣由多個 Broker 組成,Broker 負責接收和處理客戶端發送過來的請求,以及對消息進行持久化。雖然多個 Broker 進程可以運行在同一臺機器上,但更常見的作法是將不一樣的 Broker 分散運行在不一樣的機器上,這樣若是集羣中某一臺機器宕機,即便在它上面運行的全部 Broker 進程都掛掉了,其餘機器上的 Broker 也依然可以對外提供服務。這其實就是 Kafka 提供高可用的手段之一。學習

實現高可用的另外一個手段就是備份機制(Replication)。備份的思想很簡單,就是把相同的數據拷貝到多臺機器上,而這些相同的數據拷貝在 Kafka 中被稱爲副本(Replica)。好吧,其實在整個分佈式系統裏好像都叫這個名字。副本的數量是能夠配置的,這些副本保存着相同的數據,但卻有不一樣的角色和做用。spa

Kafka 定義了兩類副本:領導者副本(Leader Replica)和追隨者副本(Follower Replica)線程

  1. 前者對外提供服務,這裏的對外指的是與客戶端程序進行交互;
  2. 然後者只是被動地追隨領導者副本而已,不能與外界進行交互。固然了,你可能知道在不少其餘系統中追隨者副本是能夠對外提供服務的,好比 MySQL 的從庫是能夠處理讀操做的,可是在 Kafka 中追隨者副本不會對外提供服務。

對了,一個有意思的事情是如今已經不提倡使用 Master-Slave 來指代這種主從關係了,畢竟 Slave 有奴隸的意思,在美國這種嚴禁種族歧視的國度,這種表述有點政治不正確了,因此目前大部分的系統都改爲 Leader-Follower 了。設計

副本的工做機制也很簡單:生產者老是向領導者副本寫消息;而消費者老是從領導者副本讀消息。
至於追隨者副本,它只作一件事:向領導者副本發送請求,請求領導者把最新生產的消息發給它,這樣它能保持與領導者的同步。3d

雖然有了副本機制能夠保證數據的持久化或消息不丟失,但沒有解決伸縮性的問題。伸縮性即所謂的 Scalability,是分佈式系統中很是重要且必需要謹慎對待的問題。什麼是伸縮性呢?咱們拿副原本說,雖然如今有了領導者副本和追隨者副本,但假若領導者副本積累了太多的數據以致於單臺 Broker 機器都沒法容納了,此時應該怎麼辦呢?一個很天然的想法就是,可否把數據分割成多份保存在不一樣的 Broker 上?若是你就是這麼想的,那麼恭喜你,Kafka 就是這麼設計的。這種機制就是所謂的分區(Partitioning)日誌

若是你瞭解其餘分佈式系統,你可能據說過度片、分區域等提法,好比 MongoDB 和 Elasticsearch 中的Sharding、HBase 中的 Region,其實它們都是相同的原理,只是 Partitioning 是最標準的名稱。

Kafka 中的分區機制指的是將每一個主題劃分紅多個分區(Partition),每一個分區是一組有序的消息日誌。生產者生產的每條消息只會被髮送到一個分區中,也就是說若是向一個雙分區的主題發送一條消息,這條消息要麼在分區 0 中,要麼在分區 1 中。如你所見,Kafka的分區編號是從 0 開始的,若是 Topic 有 100 個分區,那麼它們的分區號就是從 0 到99。

講到這裏,你可能有這樣的疑問:剛纔提到的副本如何與這裏的分區聯繫在一塊兒呢?實際上,副本是在分區這個層級定義的每一個分區下能夠配置若干個副本,其中只能有 1 個領導者副本和 N-1 個追隨者副本。生產者向分區寫入消息,每條消息在分區中的位置信息由一個叫位移(Offset)的數據來表徵。

分區位移老是從 0 開始,假設一個生產者向一個空分區寫入了 10 條消息,那麼這 10 條消息的位移依次是 0、一、二、…、9。

Kafka 的三層消息架構

至此咱們可以完整地串聯起 Kafka 的三層消息架構:

  • 第一層是主題層,每一個主題能夠配置 M 個分區,而每一個分區又能夠配置 N 個副本。
  • 第二層是分區層,每一個分區的 N 個副本中只能有一個充當領導者角色,對外提供服務;其餘 N-1 個副本是追隨者副本,只是提供數據冗餘之用。
  • 第三層是消息層,分區中包含若干條消息,每條消息的位移從 0 開始,依次遞增。

最後,客戶端程序只能與分區的領導者副本進行交互。

Kafka Broker 是如何持久化數據的

講完了消息層次,咱們來講說 Kafka Broker 是如何持久化數據的。

總的來講,Kafka 使用消息日誌(Log)來保存數據,一個日誌就是磁盤上一個只能追加寫(Append-only)消息的物理文件。
由於只能追加寫入,故避免了緩慢的隨機 I/O 操做,改成性能較好的順序I/O 寫操做,這也是實現 Kafka 高吞吐量特性的一個重要手段。

不過若是你不停地向一個日誌寫入消息,最終也會耗盡全部的磁盤空間,所以 Kafka 必然要按期地刪除消息以回收
磁盤。
怎麼刪除呢?簡單來講就是經過日誌段(Log Segment)機制。在 Kafka 底層,一個日誌又近一步細分紅多個日誌段,消息被追加寫到當前最新的日誌段中,當寫滿了一個日誌段後,Kafka 會自動切分出一個新的日誌段,並將老的日誌段封存起來。Kafka 在後臺還有定時任務會按期地檢查老的日誌段是否可以被刪除,從而實現回收磁盤空間的目的。

消費者

這裏再重點說說消費者。以前提到過兩種消息模型,即點對點模型(Peerto Peer,P2P)和發佈訂閱模型。

這裏面的點對點指的是同一條消息只能被下游的一個消費者消費,其餘消費者則不能染指。在 Kafka 中實現這種 P2P 模型的方法就是引入了消費者組(Consumer Group)。所謂的消費者組,指的是多個消費者實例共同組成一個組來消費一組主題。
這組主題中的每一個分區都只會被組內的一個消費者實例消費,其餘消費者實例不能消費它。爲何要引入消費者組呢?主要是爲了提高消費者端的吞吐量。多個消費者實例同時消費,加速整個消費端的吞吐量(TPS)

後面詳細介紹消費者組機制,因此如今你只須要了解消費者組是作什麼的便可。

另外這裏的消費者實例能夠是運行消費者應用的進程,也能夠是一個線程,它們都稱爲一個消費者實例(Consumer Instance)。消費者組裏面的全部消費者實例不只「瓜分」訂閱主題的數據,並且更酷的是它們還能彼此協助。假設組內某個實例掛掉了,Kafka 可以自動檢測到,而後把這個 Failed 實例以前負責的分區轉移給其餘活着的消費者。這個過程就是 Kafka 中大名鼎鼎的「重平衡」(Rebalance)嗯,其實既是大名鼎鼎,也是臭名昭著,由於由重平衡引起的消費者問題比比皆是。事實上,目前不少重平衡的 Bug 社區都無力解決。

每一個消費者在消費消息的過程當中必然須要有個字段記錄它當前消費到了分區的哪一個位置上,這個字段就是消費者位移(Consumer Offset)。注意,這和上面所說的位移徹底不是一個概念。上面的「位移」表徵的是分區內的消息位置,它是不變的,即一旦消息被成功寫入到一個分區上,它的位移值就是固定的了
消費者位移則不一樣,它多是隨時變化的,畢竟它是消費者消費進度的指示器嘛。另外每一個消費者有着本身的消費者位移,所以必定要區分這兩類位移的區別。我我的把消息在分區中的位移稱爲分區位移,而把消費者端的位移稱
爲消費者位移。

小結

我來總結一下今天提到的全部名詞術語:

  • 消息:Record。Kafka 是消息引擎嘛,這裏的消息就是指 Kafka 處理的主要對象。
  • 主題:Topic。主題是承載消息的邏輯容器,在實際使用中多用來區分具體的業務。
  • 分區:Partition。一個有序不變的消息序列。每一個主題下能夠有多個分區。
  • 消息位移:Offset。表示分區中每條消息的位置信息,是一個單調遞增且不變的值。
  • 副本:Replica。Kafka 中同一條消息可以被拷貝到多個地方以提供數據冗餘,這些地方就是所謂的副本。副本還分爲領導者副本和追隨者副本,各自有不一樣的角色劃分。副本是在分區層級下的,即每一個分區可配置多個副本實現高可用。
  • 生產者:Producer。向主題發佈新消息的應用程序。
  • 消費者:Consumer。從主題訂閱新消息的應用程序。
  • 消費者位移:Consumer Offset。表徵消費者消費進度,每一個消費者都有本身的消費者位移。
  • 消費者組:Consumer Group。多個消費者實例共同組成的一個組,同時消費多個分區以實現高吞吐。
  • 重平衡:Rebalance。消費者組內某個消費者實例掛掉後,其餘消費者實例自動從新分配訂閱主題分區的過程。Rebalance 是 Kafka 消費者端實現高可用的重要手段

最後我用一張圖來展現上面提到的這些概念,但願這張圖可以幫助你形象化地理解全部這些

image.png

相關文章
相關標籤/搜索