大白話 + 13 張圖解 Kafka

前言

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

一、Kafka基礎

消息系統的作用

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

大白話 + 13 張圖解 Kafka


所以消息系統就是如上圖我們所說的倉庫,能在中間過程作為緩存,並且實現解耦合的作用。

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

大白話 + 13 張圖解 Kafka

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

1.Topic 主題

kafka學習了數據庫裡面的設計,在裡面設計了topic(主題),這個東西類似於關係型數據庫的表

大白話 + 13 張圖解 Kafka

此時我需要獲取中國移動的數據,那就直接監聽TopicA即可

2.Partition 分區

kafka還有一個概念叫Partition(分區),分區具體在服務器上面表現起初就是一個目錄,一個主題下面有多個分區,這些分區會存儲到不同的服務器上面,或者說,其實就是在不同的主機上建了不同的目錄。這些分區主要的信息就存在了.log文件裡面。跟數據庫裡面的分區差不多,是為了提高性能。

大白話 + 13 張圖解 Kafka

至於為什麼提高了性能,很簡單,多個分區多個線程,多個線程並行處理肯定會比單線程好得多

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

注意:1.分區會有單點故障問題,所以我們會為每個分區設置副本數

2.分區的編號是從0開始的

3.Producer - 生產者

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

大白話 + 13 張圖解 Kafka

4.Consumer - 消費者

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

大白話 + 13 張圖解 Kafka

5.Message - 消息

kafka裡面的我們處理的數據叫做消息

二、kafka的集群架構

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

大白話 + 13 張圖解 Kafka

需要注意:kafka在0.8版本以前是沒有副本機制的,所以在面對服務器宕機的突發情況時會丟失數據,所以儘量避免使用這個版本之前的kafka

Replica - 副本

kafka中的partition為了保證數據安全,所以每個partition可以設置多個副本。

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

大白話 + 13 張圖解 Kafka

而且其實每個副本都是有角色之分的,它們會選取一個副本作為leader,而其餘的作為follower,我們的生產者在發送數據的時候,是直接發送到leader partition裡面 ,然後follower partition會去leader那裡自行同步數據,消費者消費數據的時候,也是從leader那去消費數據的 。

大白話 + 13 張圖解 Kafka


Consumer Group - 消費者組

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

<code>conf.setProperty("group.id","tellYourDream")/<code>

我們所熟知的一些消息系統一般來說會這樣設計,就是隻要有一個消費者去消費了消息系統裡面的數據,那麼其餘所有的消費者都不能再去消費這個數據。可是kafka並不是這樣,比如現在consumerA去消費了一個topicA裡面的數據。

<code>consumerA:group.id = aconsumerB:group.id = aconsumerC:group.id = bconsumerD:group.id = b/<code>

再讓consumerB也去消費TopicA的數據,它是消費不到了,但是我們在consumerC中重新指定一個另外的group.id,consumerC是可以消費到topicA的數據的。而consumerD也是消費不到的,所以在kafka中,不同組可有唯一的一個消費者去消費同一主題的數據 。

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

<code>consumer group:aconsumerAconsumerBconsumerC/<code>
大白話 + 13 張圖解 Kafka

如圖,因為前面提到過了消費者會直接和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用的是順序寫,追加數據是追加到末尾,磁盤順序寫的性能極高,在磁盤個數一定,轉數達到一定的情況下,基本和內存速度一致

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

② 零拷貝

先來看看非零拷貝的情況

大白話 + 13 張圖解 Kafka

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

大白話 + 13 張圖解 Kafka

2.日誌分段存儲

Kafka規定了一個分區內的.log文件最大為1G,做這個限制目的是為了方便把.log加載到內存去操作如果大家有看前面的兩篇有關於HDFS的文章時,就會發現NameNode的edits log也會做出限制,所以這些框架都是會考慮到這些問題。


大白話 + 13 張圖解 Kafka

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

如果大家有看前面的兩篇有關於HDFS的文章時,就會發現NameNode的edits log也會做出限制,所以這些框架都是會考慮到這些問題。

3.Kafka的網絡設計

kafka的網絡設計和Kafka的調優有關,這也是為什麼它能支持高併發的原因

大白話 + 13 張圖解 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的一些基礎,在之後的更新中會繼續逐步推進,進行更加深入淺出的講解。

軟考學習資料需要的同學可以私信我哦


大白話 + 13 張圖解 Kafka


大白話 + 13 張圖解 Kafka


大白話 + 13 張圖解 Kafka


分享到:


相關文章: