架構

Kafka 優秀的架構設計!它的高性能是如何保證的?

廣告
廣告

應大部分的小伙伴的要求,今天這篇咱們用大白話帶你認識 Kafka。

Kafka 基礎

消息系統的作用

大部分小伙伴應該都清楚,這里用機油裝箱舉個例子:

所以消息系統就是如上圖我們所說的倉庫,能在中間過程作為緩存,并且實現解耦合的作用。引入一個場景,我們知道中國移動,中國聯通,中國電信的日志處理,是交給外包去做大數據分析的,假設現在它們的日志都交給了你做的系統去做用戶畫像分析。

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

Topic 主題

Kafka 學習了數據庫里面的設計,在里面設計了 Topic(主題),這個東西類似于關系型數據庫的表:

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

Partition 分區

Kafka 還有一個概念叫 Partition(分區),分區具體在服務器上面表現起初就是一個目錄。

一個主題下面有多個分區,這些分區會存儲到不同的服務器上面,或者說,其實就是在不同的主機上建了不同的目錄。這些分區主要的信息就存在了 .log 文件里面。跟數據庫里面的分區差不多,是為了提高性能。

至于為什么提高了性能,很簡單,多個分區多個線程,多個線程并行處理肯定會比單線程好得多。

Topic 和 Partition 像是 HBase 里的 Table 和 Region 的概念,Table 只是一個邏輯上的概念,真正存儲數據的是 Region。

這些 Region 會分布式地存儲在各個服務器上面,對應于 Kafka,也是一樣,Topic 也是邏輯概念,而 Partition 就是分布式存儲單元。

這個設計是保證了海量數據處理的基礎。我們可以對比一下,如果 HDFS 沒有 Block 的設計,一個 100T 的文件也只能單獨放在一個服務器上面,那就直接占滿整個服務器了,引入 Block 后,大文件可以分散存儲在不同的服務器上。

注意:

  • 分區會有單點故障問題,所以我們會為每個分區設置副本數。
  • 分區的編號是從 0 開始的。

Producer 生產者

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

Consumer 消費者

從 Kafka 里讀取數據的就是消費者:

Message 消息

Kafka 里面的我們處理的數據叫做消息。

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 集群,所有的 Broker 在啟動的時候都會往 Zookeeper 進行注冊,目的就是選舉出一個 Controller。

這個選舉過程非常簡單粗暴,就是一個誰先誰當的過程,不涉及什么算法問題。

那成為 Controller 之后要做啥呢,它會監聽 Zookeeper 里面的多個目錄,例如有一個目錄 /brokers/,其他從節點往這個目錄上**注冊(就是往這個目錄上創建屬于自己的子目錄而已)**自己。

這時命名規則一般是它們的 id 編號,比如 /brokers/0,1,2。注冊時各個節點必定會暴露自己的主機名,端口號等等的信息。

此時 Controller 就要去讀取注冊上來的從節點的數據(通過監聽機制),生成集群的元數據信息,之后把這些信息都分發給其他的服務器,讓其他服務器能感知到集群中其它成員的存在。

此時模擬一個場景,我們創建一個主題(其實就是在 Zookeeper 上 /topics/topicA 這樣創建一個目錄而已),Kafka 會把分區方案生成在這個目錄中。

此時 Controller 就監聽到了這一改變,它會去同步這個目錄的元信息,然后同樣下放給它的從節點,通過這個方法讓整個集群都得知這個分區方案,此時從節點就各自創建好目錄等待創建分區副本即可。這也是整個集群的管理機制。

加餐時間

Kafka 性能好在什么地方?

①順序寫

操作系統每次從磁盤讀寫數據的時候,需要先尋址,也就是先要找到數據在磁盤上的物理位置,然后再進行數據讀寫,如果是機械硬盤,尋址就需要較長的時間。

Kafka 的設計中,數據其實是存儲在磁盤上面,一般來說,會把數據存儲在內存上面性能才會好。

但是 Kafka 用的是順序寫,追加數據是追加到末尾,磁盤順序寫的性能極高,在磁盤個數一定,轉數達到一定的情況下,基本和內存速度一致。

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

②零拷貝

先來看看非零拷貝的情況:

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

日志分段存儲

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 也會做出限制,所以這些框架都是會考慮到這些問題。

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 網絡線程模型。

總結

集群的搭建會再找時間去提及。這一篇簡單地從角色到一些設計的方面講述了 Kafka 的一些基礎,在之后的更新中會繼續逐步推進,進行更加深入淺出的講解。

我還沒有學會寫個人說明!

41歲阿里工程師:35歲轉管理,真的是必經之路嗎?

上一篇

程序員:我終于知道post和get的區別

下一篇

你也可能喜歡

Kafka 優秀的架構設計!它的高性能是如何保證的?

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
双色球常规走势图 上海11选5走 篮球比分直播10佳球 快乐双彩今晚开奖号码 澳篮即时比分 广东快乐10分钟走势图表 河南22选5开302 四川金7乐 云南快乐十分开奖查询 幸运3D走势图 浙江快乐彩12 二人麻将平台作弊 快乐10分规则