大白話帶你認識 Kafka

原文：juejin.im/post/5dcf6b6e51882510a23314f3

前言

應大部分的小夥伴的要求，在Yarn以前先來一個kafka的小插曲，輕鬆愉快。

1、Kafka基礎

消息系統的做用

應該大部份小夥伴都清楚，用機油裝箱舉個例子

因此消息系統就是如上圖咱們所說的倉庫，能在中間過程做爲緩存，而且實現解耦合的做用。

引入一個場景，咱們知道中國移動，中國聯通，中國電信的日誌處理，是交給外包去作大數據分析的，假設如今它們的日誌都交給了你作的系統去作用戶畫像分析。

按照剛剛前面提到的消息系統的做用，咱們知道了消息系統其實就是一個模擬緩存，且僅僅是起到了緩存的做用而並非真正的緩存，數據仍然是存儲在磁盤上面而不是內存。

1.Topic 主題

kafka學習了數據庫裏面的設計，在裏面設計了topic（主題），這個東西相似於關係型數據庫的表

此時我須要獲取中國移動的數據，那就直接監聽TopicA便可

2.Partition 分區

kafka還有一個概念叫Partition（分區），分區具體在服務器上面表現起初就是一個目錄，一個主題下面有多個分區，這些分區會存儲到不一樣的服務器上面，或者說，其實就是在不一樣的主機上建了不一樣的目錄。這些分區主要的信息就存在了.log文件裏面。跟數據庫裏面的分區差很少，是爲了提升性能。

至於爲何提升了性能，很簡單，多個分區多個線程，多個線程並行處理確定會比單線程好得多

Topic和partition像是HBASE裏的table和region的概念，table只是一個邏輯上的概念，真正存儲數據的是region，這些region會分佈式地存儲在各個服務器上面，對應於kafka，也是同樣，Topic也是邏輯概念，而partition就是分佈式存儲單元。這個設計是保證了海量數據處理的基礎。咱們能夠對比一下，若是HDFS沒有block的設計，一個100T的文件也只能單獨放在一個服務器上面，那就直接佔滿整個服務器了，引入block後，大文件能夠分散存儲在不一樣的服務器上。

注意：

1. 分區會有單點故障問題，因此咱們會爲每一個分區設置副本數
2. 分區的編號是從0開始的

3.Producer - 生產者

往消息系統裏面發送數據的就是生產者

4.Consumer - 消費者

從kafka裏讀取數據的就是消費者

5.Message - 消息

kafka裏面的咱們處理的數據叫作消息

2、kafka的集羣架構

建立一個TopicA的主題，3個分區分別存儲在不一樣的服務器，也就是broker下面。Topic是一個邏輯上的概念，並不能直接在圖中把Topic的相關單元畫出

須要注意：kafka在0.8版本之前是沒有副本機制的，因此在面對服務器宕機的突發狀況時會丟失數據，因此儘可能避免使用這個版本以前的kafka

Replica - 副本

kafka中的partition爲了保證數據安全，因此每一個partition能夠設置多個副本。

此時咱們對分區0,1,2分別設置3個副本（其實設置兩個副本是比較合適的）

並且其實每一個副本都是有角色之分的，它們會選取一個副本做爲leader，而其他的做爲follower，咱們的生產者在發送數據的時候，是直接發送到leader partition裏面，而後follower partition會去leader那裏自行同步數據，消費者消費數據的時候，也是從leader那去消費數據的。

Consumer Group - 消費者組

咱們在消費數據時會在代碼裏面指定一個group.id,這個id表明的是消費組的名字，並且這個group.id就算不設置，系統也會默認設置

conf.setProperty("group.id","tellYourDream")

咱們所熟知的一些消息系統通常來講會這樣設計，就是隻要有一個消費者去消費了消息系統裏面的數據，那麼其他全部的消費者都不能再去消費這個數據。但是kafka並非這樣,好比如今consumerA去消費了一個topicA裏面的數據。

consumerA:    
  group.id = a
consumerB:    
   group.id = a    
   
consumerC:    
   group.id = b
consumerD:    
   group.id = b

再讓consumerB也去消費TopicA的數據，它是消費不到了，可是咱們在consumerC中從新指定一個另外的group.id，consumerC是能夠消費到topicA的數據的。而consumerD也是消費不到的，因此在kafka中，不一樣組可有惟一的一個消費者去消費同一主題的數據。

因此消費者組就是讓多個消費者並行消費信息而存在的，並且它們不會消費到同一個消息，以下，consumerA，B，C是不會互相干擾的

consumer group:a    
    consumerA    
    consumerB    
    consumerC

如圖，由於前面提到過了消費者會直接和leader創建聯繫，因此它們分別消費了三個leader，因此一個分區不會讓消費者組裏面的多個消費者去消費，可是在消費者不飽和的狀況下，一個消費者是能夠去消費多個分區的數據的。

Controller

熟知一個規律：在大數據分佈式文件系統裏面，95%的都是主從式的架構，個別是對等式的架構，好比ElasticSearch。

kafka也是主從式的架構，主節點就叫controller，其他的爲從節點，controller是須要和zookeeper進行配合管理整個kafka集羣。

kafka和zookeeper如何配合工做

kafka嚴重依賴於zookeeper集羣（因此以前的zookeeper文章仍是有點用的）。全部的broker在啓動的時候都會往zookeeper進行註冊，目的就是選舉出一個controller，這個選舉過程很是簡單粗暴，就是一個誰先誰當的過程，不涉及什麼算法問題。

那成爲controller以後要作啥呢，它會監聽zookeeper裏面的多個目錄，例若有一個目錄/brokers/，其餘從節點往這個目錄上**註冊（就是往這個目錄上建立屬於本身的子目錄而已）**本身，這時命名規則通常是它們的id編號，好比/brokers/0,1,2

註冊時各個節點一定會暴露本身的主機名，端口號等等的信息，此時controller就要去讀取註冊上來的從節點的數據（經過監聽機制），生成集羣的元數據信息，以後把這些信息都分發給其餘的服務器，讓其餘服務器能感知到集羣中其它成員的存在。

此時模擬一個場景，咱們建立一個主題（其實就是在zookeeper上/topics/topicA這樣建立一個目錄而已），kafka會把分區方案生成在這個目錄中，此時controller就監聽到了這一改變，它會去同步這個目錄的元信息，而後一樣下放給它的從節點，經過這個方法讓整個集羣都得知這個分區方案，此時從節點就各自建立好目錄等待建立分區副本便可。這也是整個集羣的管理機制。

加餐時間

1.Kafka性能好在什麼地方？

① 順序寫

操做系統每次從磁盤讀寫數據的時候，須要先尋址，也就是先要找到數據在磁盤上的物理位置，而後再進行數據讀寫，若是是機械硬盤，尋址就須要較長的時間。

kafka的設計中，數據實際上是存儲在磁盤上面，通常來講，會把數據存儲在內存上面性能纔會好。可是kafka用的是順序寫，追加數據是追加到末尾，磁盤順序寫的性能極高，在磁盤個數必定，轉數達到必定的狀況下，基本和內存速度一致

隨機寫的話是在文件的某個位置修改數據，性能會較低。

② 零拷貝

先來看看非零拷貝的狀況

能夠看到數據的拷貝從內存拷貝到kafka服務進程那塊，又拷貝到socket緩存那塊，整個過程耗費的時間比較高，kafka利用了Linux的sendFile技術（NIO），省去了進程切換和一次數據拷貝，讓性能變得更好。

2.日誌分段存儲

Kafka規定了一個分區內的.log文件最大爲1G，作這個限制目的是爲了方便把.log加載到內存去操做

00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex

00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex

00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex

這個9936472之類的數字，就是表明了這個日誌段文件裏包含的起始offset，也就說明這個分區裏至少都寫入了接近1000萬條數據了。Kafka broker有一個參數，log.segment.bytes，限定了每一個日誌段文件的大小，最大就是1GB，一個日誌段文件滿了，就自動開一個新的日誌段文件來寫入，避免單個文件過大，影響文件的讀寫性能，這個過程叫作log rolling，正在被寫入的那個日誌段文件，叫作active log segment。

若是你們有看前面的兩篇有關於HDFS的文章時，就會發現NameNode的edits log也會作出限制，因此這些框架都是會考慮到這些問題。

3.Kafka的網絡設計

kafka的網絡設計和Kafka的調優有關，這也是爲何它能支持高併發的緣由

首先客戶端發送請求所有會先發送給一個Acceptor，broker裏面會存在3個線程（默認是3個），這3個線程都是叫作processor，Acceptor不會對客戶端的請求作任何的處理，直接封裝成一個個socketChannel發送給這些processor造成一個隊列，發送的方式是輪詢，就是先給第一個processor發送，而後再給第二個，第三個，而後又回到第一個。消費者線程去消費這些socketChannel時，會獲取一個個request請求，這些request請求中就會伴隨着數據。

線程池裏面默認有8個線程，這些線程是用來處理request的，解析請求，若是request是寫請求，就寫到磁盤裏。讀的話返回結果。

processor會從response中讀取響應數據，而後再返回給客戶端。這就是Kafka的網絡三層架構。

因此若是咱們須要對kafka進行加強調優，增長processor並增長線程池裏面的處理線程，就能夠達到效果。request和response那一塊部分其實就是起到了一個緩存的效果，是考慮到processor們生成請求太快，線程數不夠不能及時處理的問題。

因此這就是一個增強版的reactor網絡線程模型。

finally

集羣的搭建會再找時間去說起。這一篇簡單地從角色到一些設計的方面講述了Kafka的一些基礎，在以後的更新中會繼續逐步推動，進行更加深刻淺出的講解。

若有錯誤或其它問題，歡迎小夥伴留言評論、指正。若有幫助，歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號：民工哥技術之路