大白話(huà)聊聊 Kafka 的架構(gòu)原理和網(wǎng)絡(luò)設(shè)計(jì),它的性能高在什么地方?
一、Kafka基礎(chǔ)
消息系統(tǒng)的作用
應(yīng)該大部分小伙伴都清楚,用機(jī)油裝箱舉個(gè)例子:
消息系統(tǒng)就是我們所說(shuō)的倉(cāng)庫(kù),能在中間過(guò)程作為緩存,并且實(shí)現(xiàn)解耦合的作用。
引入一個(gè)場(chǎng)景,我們知道中國(guó)移動(dòng),中國(guó)聯(lián)通,中國(guó)電信的日志處理,是交給外包去做大數(shù)據(jù)分析的,假設(shè)現(xiàn)在它們的日志都交給了你做的系統(tǒng)去做用戶(hù)畫(huà)像分析。
按照剛剛前面提到的消息系統(tǒng)的作用,我們知道了消息系統(tǒng)其實(shí)就是一個(gè)模擬緩存,且僅僅是起到了緩存的作用而并不是真正的緩存,數(shù)據(jù)仍然是存儲(chǔ)在磁盤(pán)上面而不是內(nèi)存。
1.Topic 主題
kafka學(xué)習(xí)了數(shù)據(jù)庫(kù)里面的設(shè)計(jì),在里面設(shè)計(jì)了topic(主題),這個(gè)東西類(lèi)似于關(guān)系型數(shù)據(jù)庫(kù)的表。
此時(shí)我需要獲取中國(guó)移動(dòng)的數(shù)據(jù),那就直接監(jiān)聽(tīng)TopicA即可。
2.Partition 分區(qū)
kafka還有一個(gè)概念叫Partition(分區(qū)),分區(qū)具體在服務(wù)器上面表現(xiàn)起初就是一個(gè)目錄,一個(gè)主題下面有多個(gè)分區(qū),這些分區(qū)會(huì)存儲(chǔ)到不同的服務(wù)器上面,或者說(shuō),其實(shí)就是在不同的主機(jī)上建了不同的目錄。這些分區(qū)主要的信息就存在了.log文件里面。跟數(shù)據(jù)庫(kù)里面的分區(qū)差不多,是為了提高性能。
至于為什么提高了性能,很簡(jiǎn)單,多個(gè)分區(qū)多個(gè)線(xiàn)程,多個(gè)線(xiàn)程并行處理肯定會(huì)比單線(xiàn)程好得多。
Topic和partition像是HBASE里的table和region的概念,table只是一個(gè)邏輯上的概念,真正存儲(chǔ)數(shù)據(jù)的是region,這些region會(huì)分布式地存儲(chǔ)在各個(gè)服務(wù)器上面,對(duì)應(yīng)于kafka,也是一樣,Topic也是邏輯概念,而partition就是分布式存儲(chǔ)單元。
這個(gè)設(shè)計(jì)是保證了海量數(shù)據(jù)處理的基礎(chǔ)。我們可以對(duì)比一下,如果HDFS沒(méi)有block的設(shè)計(jì),一個(gè)100T的文件也只能單獨(dú)放在一個(gè)服務(wù)器上面,那就直接占滿(mǎn)整個(gè)服務(wù)器了,引入block后,大文件可以分散存儲(chǔ)在不同的服務(wù)器上。
注意:
-
分區(qū)會(huì)有單點(diǎn)故障問(wèn)題,所以我們會(huì)為每個(gè)分區(qū)設(shè)置副本數(shù)
-
分區(qū)的編號(hào)是從0開(kāi)始的
3.Producer - 生產(chǎn)者
往消息系統(tǒng)里面發(fā)送數(shù)據(jù)的就是生產(chǎn)者
4.Consumer - 消費(fèi)者
從kafka里讀取數(shù)據(jù)的就是消費(fèi)者
5.Message - 消息
kafka里面的我們處理的數(shù)據(jù)叫做消息
二、kafka的集群架構(gòu)
創(chuàng)建一個(gè)TopicA的主題,3個(gè)分區(qū)分別存儲(chǔ)在不同的服務(wù)器,也就是broker下面。Topic是一個(gè)邏輯上的概念,并不能直接在圖中把Topic的相關(guān)單元畫(huà)出。
需要注意:kafka在0.8版本以前是沒(méi)有副本機(jī)制的,所以在面對(duì)服務(wù)器宕機(jī)的突發(fā)情況時(shí)會(huì)丟失數(shù)據(jù),所以盡量避免使用這個(gè)版本之前的kafka
Replica - 副本
kafka中的partition為了保證數(shù)據(jù)安全,所以每個(gè)partition可以設(shè)置多個(gè)副本。
此時(shí)我們對(duì)分區(qū)0,1,2分別設(shè)置3個(gè)副本(其實(shí)設(shè)置兩個(gè)副本是比較合適的)
而且其實(shí)每個(gè)副本都是有角色之分的,它們會(huì)選取一個(gè)副本作為leader,而其余的作為follower,我們的生產(chǎn)者在發(fā)送數(shù)據(jù)的時(shí)候,是直接發(fā)送到leader partition里面。
然后follower partition會(huì)去leader那里自行同步數(shù)據(jù),消費(fèi)者消費(fèi)數(shù)據(jù)的時(shí)候,也是從leader那去消費(fèi)數(shù)據(jù)的。
Consumer Group - 消費(fèi)者組
我們?cè)谙M(fèi)數(shù)據(jù)時(shí)會(huì)在代碼里面指定一個(gè)group.id,這個(gè)id代表的是消費(fèi)組的名字,而且這個(gè)group.id就算不設(shè)置,系統(tǒng)也會(huì)默認(rèn)設(shè)置
conf.setProperty("group.id","tellYourDream")
我們所熟知的一些消息系統(tǒng)一般來(lái)說(shuō)會(huì)這樣設(shè)計(jì),就是只要有一個(gè)消費(fèi)者去消費(fèi)了消息系統(tǒng)里面的數(shù)據(jù),那么其余所有的消費(fèi)者都不能再去消費(fèi)這個(gè)數(shù)據(jù)。
可是kafka并不是這樣,比如現(xiàn)在consumerA去消費(fèi)了一個(gè)topicA里面的數(shù)據(jù)。
consumerA: group.id = a consumerB: group.id = a consumerC: group.id = b consumerD: group.id = b
再讓consumerB也去消費(fèi)TopicA的數(shù)據(jù),它是消費(fèi)不到了,但是我們?cè)赾onsumerC中重新指定一個(gè)另外的group.id,consumerC是可以消費(fèi)到topicA的數(shù)據(jù)的。而consumerD也是消費(fèi)不到的,所以在kafka中,不同組可有唯一的一個(gè)消費(fèi)者去消費(fèi)同一主題的數(shù)據(jù)。
所以消費(fèi)者組就是讓多個(gè)消費(fèi)者并行消費(fèi)信息而存在的,而且它們不會(huì)消費(fèi)到同一個(gè)消息,如下,consumerA,B,C是不會(huì)互相干擾的
consumer group:a
consumerA
consumerB
consumerC
因?yàn)榍懊嫣岬竭^(guò)了消費(fèi)者會(huì)直接和leader建立聯(lián)系,所以它們分別消費(fèi)了三個(gè)leader,所以一個(gè)分區(qū)不會(huì)讓消費(fèi)者組里面的多個(gè)消費(fèi)者去消費(fèi),但是在消費(fèi)者不飽和的情況下,一個(gè)消費(fèi)者是可以去消費(fèi)多個(gè)分區(qū)的數(shù)據(jù)的。
Controller
熟知一個(gè)規(guī)律:在大數(shù)據(jù)分布式文件系統(tǒng)里面,95%的都是主從式的架構(gòu),個(gè)別是對(duì)等式的架構(gòu),比如ElasticSearch。
kafka也是主從式的架構(gòu),主節(jié)點(diǎn)就叫controller,其余的為從節(jié)點(diǎn),controller是需要和zookeeper進(jìn)行配合管理整個(gè)kafka集群。
kafka和zookeeper如何配合工作
kafka嚴(yán)重依賴(lài)于zookeeper集群(所以之前的zookeeper文章還是有點(diǎn)用的)。
所有的broker在啟動(dòng)的時(shí)候都會(huì)往zookeeper進(jìn)行注冊(cè),目的就是選舉出一個(gè)controller,這個(gè)選舉過(guò)程非常簡(jiǎn)單粗暴,就是一個(gè)誰(shuí)先誰(shuí)當(dāng)?shù)倪^(guò)程,不涉及什么算法問(wèn)題。
那成為controller之后要做啥呢,它會(huì)監(jiān)聽(tīng)zookeeper里面的多個(gè)目錄,例如有一個(gè)目錄/brokers/,其他從節(jié)點(diǎn)往這個(gè)目錄上注冊(cè)(就是往這個(gè)目錄上創(chuàng)建屬于自己的子目錄而已)自己,這時(shí)命名規(guī)則一般是它們的id編號(hào),比如/brokers/0,1,2
注冊(cè)時(shí)各個(gè)節(jié)點(diǎn)必定會(huì)暴露自己的主機(jī)名,端口號(hào)等等的信息,此時(shí)controller就要去讀取注冊(cè)上來(lái)的從節(jié)點(diǎn)的數(shù)據(jù)(通過(guò)監(jiān)聽(tīng)機(jī)制),生成集群的元數(shù)據(jù)信息,之后把這些信息都分發(fā)給其他的服務(wù)器,讓其他服務(wù)器能感知到集群中其它成員的存在。
此時(shí)模擬一個(gè)場(chǎng)景,我們創(chuàng)建一個(gè)主題(其實(shí)就是在zookeeper上/topics/topicA這樣創(chuàng)建一個(gè)目錄而已),kafka會(huì)把分區(qū)方案生成在這個(gè)目錄中,此時(shí)controller就監(jiān)聽(tīng)到了這一改變,它會(huì)去同步這個(gè)目錄的元信息,然后同樣下放給它的從節(jié)點(diǎn),通過(guò)這個(gè)方法讓整個(gè)集群都得知這個(gè)分區(qū)方案,此時(shí)從節(jié)點(diǎn)就各自創(chuàng)建好目錄等待創(chuàng)建分區(qū)副本即可。這也是整個(gè)集群的管理機(jī)制。
加餐時(shí)間
1.Kafka性能好在什么地方?
① 順序?qū)?/strong>
操作系統(tǒng)每次從磁盤(pán)讀寫(xiě)數(shù)據(jù)的時(shí)候,需要先尋址,也就是先要找到數(shù)據(jù)在磁盤(pán)上的物理位置,然后再進(jìn)行數(shù)據(jù)讀寫(xiě),如果是機(jī)械硬盤(pán),尋址就需要較長(zhǎng)的時(shí)間。
kafka的設(shè)計(jì)中,數(shù)據(jù)其實(shí)是存儲(chǔ)在磁盤(pán)上面,一般來(lái)說(shuō),會(huì)把數(shù)據(jù)存儲(chǔ)在內(nèi)存上面性能才會(huì)好。但是kafka用的是順序?qū)懀芳訑?shù)據(jù)是追加到末尾,磁盤(pán)順序?qū)懙男阅軜O高,在磁盤(pán)個(gè)數(shù)一定,轉(zhuǎn)數(shù)達(dá)到一定的情況下,基本和內(nèi)存速度一致
隨機(jī)寫(xiě)的話(huà)是在文件的某個(gè)位置修改數(shù)據(jù),性能會(huì)較低。
② 零拷貝
先來(lái)看看非零拷貝的情況,數(shù)據(jù)的拷貝從內(nèi)存拷貝到kafka服務(wù)進(jìn)程那塊,又拷貝到socket緩存那塊,整個(gè)過(guò)程耗費(fèi)的時(shí)間比較高,kafka利用了Linux的sendFile技術(shù)(NIO),省去了進(jìn)程切換和一次數(shù)據(jù)拷貝,讓性能變得更好。
2.日志分段存儲(chǔ)
Kafka規(guī)定了一個(gè)分區(qū)內(nèi)的.log文件最大為1G,做這個(gè)限制目的是為了方便把.log加載到內(nèi)存去操作
00000000000000000000.index 00000000000000000000.log 00000000000000000000.timeindex 00000000000005367851.index 00000000000005367851.log 00000000000005367851.timeindex 00000000000009936472.index 00000000000009936472.log 00000000000009936472.timeindex
這個(gè)9936472之類(lèi)的數(shù)字,就是代表了這個(gè)日志段文件里包含的起始o(jì)ffset,也就說(shuō)明這個(gè)分區(qū)里至少都寫(xiě)入了接近1000萬(wàn)條數(shù)據(jù)了。
Kafka broker有一個(gè)參數(shù),log.segment.bytes,限定了每個(gè)日志段文件的大小,最大就是1GB,一個(gè)日志段文件滿(mǎn)了,就自動(dòng)開(kāi)一個(gè)新的日志段文件來(lái)寫(xiě)入,避免單個(gè)文件過(guò)大,影響文件的讀寫(xiě)性能,這個(gè)過(guò)程叫做log rolling,正在被寫(xiě)入的那個(gè)日志段文件,叫做active log segment。
如果大家有看前面的兩篇有關(guān)于HDFS的文章時(shí),就會(huì)發(fā)現(xiàn)NameNode的edits log也會(huì)做出限制,所以這些框架都是會(huì)考慮到這些問(wèn)題。
3.Kafka的網(wǎng)絡(luò)設(shè)計(jì)
kafka的網(wǎng)絡(luò)設(shè)計(jì)和Kafka的調(diào)優(yōu)有關(guān),這也是為什么它能支持高并發(fā)的原因。
首先客戶(hù)端發(fā)送請(qǐng)求全部會(huì)先發(fā)送給一個(gè)Acceptor,broker里面會(huì)存在3個(gè)線(xiàn)程(默認(rèn)是3個(gè)),這3個(gè)線(xiàn)程都是叫做processor,Acceptor不會(huì)對(duì)客戶(hù)端的請(qǐng)求做任何的處理,直接封裝成一個(gè)個(gè)socketChannel發(fā)送給這些processor形成一個(gè)隊(duì)列。
發(fā)送的方式是輪詢(xún),就是先給第一個(gè)processor發(fā)送,然后再給第二個(gè),第三個(gè),然后又回到第一個(gè)。消費(fèi)者線(xiàn)程去消費(fèi)這些socketChannel時(shí),會(huì)獲取一個(gè)個(gè)request請(qǐng)求,這些request請(qǐng)求中就會(huì)伴隨著數(shù)據(jù)。
線(xiàn)程池里面默認(rèn)有8個(gè)線(xiàn)程,這些線(xiàn)程是用來(lái)處理request的,解析請(qǐng)求,如果request是寫(xiě)請(qǐng)求,就寫(xiě)到磁盤(pán)里。讀的話(huà)返回結(jié)果。
processor會(huì)從response中讀取響應(yīng)數(shù)據(jù),然后再返回給客戶(hù)端。這就是Kafka的網(wǎng)絡(luò)三層架構(gòu)。
所以如果我們需要對(duì)kafka進(jìn)行增強(qiáng)調(diào)優(yōu),增加processor并增加線(xiàn)程池里面的處理線(xiàn)程,就可以達(dá)到效果。request和response那一塊部分其實(shí)就是起到了一個(gè)緩存的效果,是考慮到processor們生成請(qǐng)求太快,線(xiàn)程數(shù)不夠不能及時(shí)處理的問(wèn)題。
所以,這就是一個(gè)加強(qiáng)版的reactor網(wǎng)絡(luò)線(xiàn)程模型。
finally
集群的搭建會(huì)再找時(shí)間去提及。這一篇簡(jiǎn)單地從角色到一些設(shè)計(jì)的方面講述了Kafka的一些基礎(chǔ),在之后的更新中會(huì)繼續(xù)逐步推進(jìn),進(jìn)行更加深入淺出的講解。
作者:說(shuō)出你的愿望吧
juejin.im/post/5dcf6b6e51882510a23314f3
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒(méi)關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:
![]()
![]()
![]()
長(zhǎng)按訂閱更多精彩▼
![]()
如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀(guān)點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!