kafka詳解1、Kafka簡介

背景：

     當今社會各類應用系統諸如商業、社交、搜索、瀏覽等像信息工廠同樣不斷的生產出各類信息，在大數據時代，咱們面臨以下幾個挑戰：

1. 如何收集這些巨大的信息
2. 如何分析它       
3. 如何及時作到如上兩點

     以上幾個挑戰造成了一個業務需求模型，即生產者生產（produce）各類信息，消費者消費（consume）（處理分析）這些信息，而在生產者與消費者之間，須要一個溝通二者的橋樑-消息系統。

     從一個微觀層面來講，這種需求也可理解爲不一樣的系統之間如何傳遞消息。

 

Kafka誕生：由 linked-in 開源

 

kafka-便是解決這類問題的一個框架，它實現了生產者和消費者之間的無縫鏈接。

kafka-高產出的分佈式消息系統(A high-throughput distributed messaging system)

 

Kafka特性：它形容本身的設計是獨一無二的，先看一下它有如何過人之處：

 

• 快：單個kafka服務每秒可處理數以千計客戶端發來的幾百MB數據。
• 可擴展性：一個單一集羣可做爲一個大數據處理中樞，集中處理各類類型業務
• 持久化：消息被持久化到磁盤（可處理TB數據級別數據但仍保持極高數據處理效率），而且有備份容錯機制
• 分佈式：着眼於大數據領域，支持分佈式，集羣可處理每秒百萬級別消息
• 實時性：生產出的消息可當即被消費者消費

Kafka的組件：

• topic：消息存放的目錄即主題
• Producer：生產消息到topic的一方
• Consumer：訂閱topic消費消息的一方    
• Broker：Kafka的服務實例就是一個broker

以下圖所示，Producer生產的消息經過網絡發送給Kafka cluster，而Consumer從其中消費消息

Topic 和Partition:

 

     消息發送時都被髮送到一個topic，其本質就是一個目錄，而topic由是由一些Partition Logs(分區日誌)組成,其組織結構以下圖所示：

     咱們能夠看到，每一個Partition中的消息都是有序的，生產的消息被不斷追加到Partition log上，其中的每個消息都被賦予了一個惟一的offset值。

     Kafka集羣會保存全部的消息，無論消息有沒有被消費；咱們能夠設定消息的過時時間，只有過時的數據纔會被自動清除以釋放磁盤空間。好比咱們設置消息過時時間爲2天，那麼這2天內的全部消息都會被保存到集羣中，數據只有超過了兩天才會被清除。

     Kafka須要維持的元數據只有一個--消費消息在Partition中的offset值，Consumer每消費一個消息，offset就會加1。其實消息的狀態徹底是由Consumer控制的，Consumer能夠跟蹤和重設這個offset值，這樣的話Consumer就能夠讀取任意位置的消息。

     把消息日誌以Partition的形式存放有多重考慮，第一，方便在集羣中擴展，每一個Partition能夠經過調整以適應它所在的機器，而一個topic又能夠有多個Partition組成，所以整個集羣就能夠適應任意大小的數據了；第二就是能夠提升併發，由於能夠以Partition爲單位讀寫了。

     

分佈式：

     這些Partitions分佈在集羣的每一臺server上，而每個Partition在集羣中均可以有多個備份，這個備份數量是可配置的。

     每一個Partition都有一個leader server，而其餘備份的server都稱爲followers，只有leader服務器纔會處理這個Partition上全部的讀寫請求，而其它followers則被動的複製leader上的數據。若是一個leader掛掉了，followers中的一個服務器則會自動升級爲leader。所以，其實集羣中的每一個服務器都扮演着一個Partition的leader服務器，和其它Partition的follower服務器。

 

Producers:

     Producer能夠根據本身的選擇發佈消息到一個主題，Producer也能夠本身決定把消息發佈到這個主題的哪一個Partition，固然咱們能夠選擇API提供的簡單的分區選擇算法，也能夠本身去實現一個分區選擇算法。

 

Consumers:

     消息傳遞一般由兩種模式，queuing（隊列）和publish-subscribe （發佈-訂閱）

• queuing：每一個Consumer從消息隊列中取走一個消息
• pub-scrib:消息被廣播到每一個Consumer     

     Kafka經過提供了一個對Consumer的抽象來同時實現這兩種模式-ConsumerGroup。Consumer實例須要給本身指定一個ConsumerGroup的名字，若是全部的實例都用同一個ConsumerGroup名字，那麼這些Consumer就會以queuing的模式工做；若是全部的實例分別用的不一樣的ConsumerGroup名字，那麼它們就以public-subscribe模式工做。

 

以下圖所示：含兩臺server的集羣一共有p0~p3四個Partition，兩個Consumer Group，在Group內部是以queuing的模式消費Partition，在Group之間是以pub-scrib模式消費。

    

消息順序性：

     Kafka是如何確保消息消費的順序性的呢？前面講到過Partition，消息在一個Partition中的順序是有序的，可是Kafka只保證消息在一個Partition中有序，若是要想使整個topic中的消息有序，那麼一個topic僅設置一個Partition便可。

 

 

 

 

想更深刻的瞭解Kafka請參閱個人另外一篇文章：《Kafka設計與原理詳解》