kafka架構(gòu)原理
點擊上方“IT那活兒”公眾號,關(guān)注后了解更多內(nèi)容,不管IT什么活兒,干就完了!?。?/strong>
kafka是一個分布式、支持分區(qū)的(partition)、多副本的(replica),基于zookeeper協(xié)調(diào)的分布式消息系統(tǒng),它的最大的特性就是可以實時的處理大量數(shù)據(jù)以滿足各種需求場景。
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng),它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù),具有高性能、持久化、多副本備份、橫向擴展能力。2.1 基礎(chǔ)架構(gòu)與名詞解釋
- Producer:Producer即生產(chǎn)者,消息的產(chǎn)生者,是消息的入口。
- Broker:Broker是kafka實例,每個服務(wù)器上有一個或多個kafka的實例,我們姑且認為每個broker對應(yīng)一臺服務(wù)器。每個kafka集群內(nèi)的broker都有一個不重復(fù)的編號,如圖中的broker-0、broker-1等……
- Topic:消息的主題,可以理解為消息的分類,kafka的數(shù)據(jù)就保存在topic。在每個broker上都可以創(chuàng)建多個topic。
- Partition:Topic的分區(qū),每個topic可以有多個分區(qū),分區(qū)的作用是做負載,提高kafka的吞吐量。同一個topic在不同的分區(qū)的數(shù)據(jù)是不重復(fù)的,partition的表現(xiàn)形式就是一個一個的文件夾!
- Replication:每一個分區(qū)都有多個副本,副本的作用是做備胎。當(dāng)主分區(qū)(Leader)故障的時候會選擇一個備胎(Follower)上位,成為Leader。在kafka中默認副本的最大數(shù)量是10個,且副本的數(shù)量不能大于Broker的數(shù)量,follower和leader絕對是在不同的機器,同一機器對同一個分區(qū)也只可能存放一個副本(包括自己)。
- Consumer:消費者,即消息的消費方,是消息的出口。
- Consumer Group:我們可以將多個消費組組成一個消費者組,在kafka的設(shè)計中同一個分區(qū)的數(shù)據(jù)只能被消費者組中的某一個消費者消費。同一個消費者組的消費者可以消費同一個topic的不同分區(qū)的數(shù)據(jù),這也是為了提高kafka的吞吐量!
- Zookeeper:kafka集群依賴zookeeper來保存集群的的元信息,來保證系統(tǒng)的可用性。
2.2 工作流程分析
2.2.1 發(fā)送數(shù)據(jù)
Producer在寫入數(shù)據(jù)的時候永遠的找leader,不會直接將數(shù)據(jù)寫入follower!那leader怎么找呢?寫入的流程又是什么樣的呢?我們看下圖:注意:消息寫入leader后,follower是主動的去leader進行同步的!producer采用push模式將數(shù)據(jù)發(fā)布到broker,每條消息追加到分區(qū)中,順序?qū)懭氪疟P,所以保證同一分區(qū)內(nèi)的數(shù)據(jù)是有序的!寫入示意圖如下:kafka為什么要做分區(qū)呢?分區(qū)的主要目的是:
- 方便擴展:因為一個topic可以有多個partition,所以我們可以通過擴展機器去輕松的應(yīng)對日益增長的數(shù)據(jù)量。
- 提高并發(fā):以partition為讀寫單位,可以多個消費者同時消費數(shù)據(jù),提高了消息的處理效率。
在kafka中,如果某個topic有多個partition,producer又怎么知道該將數(shù)據(jù)發(fā)往哪個partition呢?kafka中有幾個原則:- partition在寫入的時候可以指定需要寫入的partition,如果有指定,則寫入對應(yīng)的partition。
- 如果沒有指定partition,但是設(shè)置了數(shù)據(jù)的key,則會根據(jù)key的值hash出一個partition。
- 如果既沒指定partition,又沒有設(shè)置key,則會輪詢選出一個partition。
保證消息不丟失是一個消息隊列中間件的基本保證,那producer在向kafka寫入消息的時候,怎么保證消息不丟失呢?通過上圖中的通過ACK應(yīng)答機制!在生產(chǎn)者向隊列寫入數(shù)據(jù)的時候可以設(shè)置參數(shù)來確定是否確認kafka接收到數(shù)據(jù),這個參數(shù)可設(shè)置的值為0、1、all。
- 0代表producer往集群發(fā)送數(shù)據(jù)不需要等到集群的返回,不確保消息發(fā)送成功。安全性最低但是效率最高。
- 1代表producer往集群發(fā)送數(shù)據(jù)只要leader應(yīng)答就可以發(fā)送下一條,只確保leader發(fā)送成功。
- all代表producer往集群發(fā)送數(shù)據(jù)需要所有的follower都完成從leader的同步才會發(fā)送下一條,確保leader發(fā)送成功和所有的副本都完成備份。安全性最高,但是效率最低。
注意:如果往不存在的topic寫數(shù)據(jù),能不能寫入成功呢?kafka會自動創(chuàng)建topic,分區(qū)和副本的數(shù)量根據(jù)默認配置都是1。2.2.2 保存數(shù)據(jù)
Producer將數(shù)據(jù)寫入kafka后,集群就需要對數(shù)據(jù)進行保存了!kafka將數(shù)據(jù)保存在磁盤,可能在我們的一般的認知里,寫入磁盤是比較耗時的操作,不適合這種高并發(fā)的組件。Kafka初始會多帶帶開辟一塊磁盤空間,順序?qū)懭霐?shù)據(jù)(效率比隨機寫入高)。Partition在服務(wù)器上的表現(xiàn)形式就是一個一個的文件夾,每個partition的文件夾下面會有多組segment文件,每組segment文件又包含.index文件、.log文件、.timeindex文件(早期版本中沒有)三個文件, log文件就實際是存儲message的地方,而index和timeindex文件為索引文件,用于檢索消息。如上圖,這個partition有三組segment文件,每個log文件的大小是一樣的,但是存儲的message數(shù)量是不一定相等的(每條的message大小不一致)。文件的命名是以該segment最小offset來命名的,如000.index存儲offset為0~368795的消息,kafka就是利用分段+索引的方式來解決查找效率的問題。log文件就實際是存儲message的地方,我們在producer往kafka寫入的也是一條一條的message,那存儲在log中的message是什么樣子的呢?消息主要包含消息體、消息大小、offset、壓縮類型……等等!
我們重點需要知道的是下面三個:
- offset:offset是一個占8byte的有序id號,它可以唯一確定每條消息在parition內(nèi)的位置!
- 消息大?。合⒋笮≌加?byte,用于描述消息的大小。
- 消息體:消息體存放的是實際的消息數(shù)據(jù)(被壓縮過),占用的空間根據(jù)具體的消息而不一樣。
無論消息是否被消費,kafka都會保存所有的消息。那對于舊數(shù)據(jù)有什么刪除策略呢?
注意:kafka讀取特定消息的時間復(fù)雜度是O(1),所以這里刪除過期的文件并不會提高kafka的性能!2.2.3 消費數(shù)據(jù)
一般消息系統(tǒng),consumer存在兩種消費模型:
- push:優(yōu)勢在于消息實時性高。劣勢在于沒有考慮consumer消費能力和飽和情況,容易導(dǎo)致producer壓垮consumer。
- pull:優(yōu)勢在可以控制消費速度和消費數(shù)量,保證consumer不會出現(xiàn)飽和。劣勢在于當(dāng)沒有數(shù)據(jù),會出現(xiàn)空輪詢,消耗cpu。
Kafka采用的是pull模式,消費者主動的去kafka集群拉取消息,與producer相同的是,消費者在拉取消息的時候也是找leader去拉取。多個消費者可以組成一個消費者組(consumer group),每個消費者組都有一個組id!同一個消費組者的消費者可以消費同一topic下不同分區(qū)的數(shù)據(jù),但是不會組內(nèi)多個消費者消費同一分區(qū)的數(shù)據(jù)?。?!我們看下圖:注意:圖示是消費者組內(nèi)的消費者小于partition數(shù)量的情況,所以會出現(xiàn)某個消費者消費多個partition數(shù)據(jù)的情況,消費的速度也就不及只處理一個partition的消費者的處理速度!如果是消費者組的消費者多于partition的數(shù)量,那會不會出現(xiàn)多個消費者消費同一個partition的數(shù)據(jù)呢?上面已經(jīng)提到過不會出現(xiàn)這種情況!多出來的消費者不消費任何partition的數(shù)據(jù)。所以在實際的應(yīng)用中,建議消費者組的consumer的數(shù)量與partition的數(shù)量一致!在保存數(shù)據(jù)的小節(jié)里面,我們聊到了partition劃分為多組segment,每個segment又包含.log、.index、.timeindex文件,存放的每條message包含offset、消息大小、消息體……我們多次提到segment和offset,查找消息的時候是怎么利用segment+offset配合查找的呢?假如現(xiàn)在需要查找一個offset為368801的message是什么樣的過程呢?我們先看看下面的圖:- 1)先找到offset的368801message所在的segment文件(利用二分法查找),這里找到的就是在第二個segment文件。
- 2)打開找到的segment中的.index文件(也就是368796.index文件,該文件起始偏移量為368796+1,我們要查找的offset為368801的message在該index內(nèi)的偏移量為368796+5=368801,所以這里要查找的相對offset為5)。由于該文件采用的是稀疏索引的方式存儲著相對offset及對應(yīng)message物理偏移量的關(guān)系,所以直接找相對offset為5的索引找不到,這里同樣利用二分法查找相對offset小于或者等于指定的相對offset的索引條目中最大的那個相對offset,所以找到的是相對offset為4的這個索引。
- 3)根據(jù)找到的相對offset為4的索引確定message存儲的物理偏移位置為256。打開數(shù)據(jù)文件,從位置為256的那個地方開始順序掃描直到找到offset為368801的那條Message。
這套機制是建立在offset為有序的基礎(chǔ)上,利用segment+有序offset+稀疏索引+二分查找+順序查找等多種手段來高效的查找數(shù)據(jù)!至此,消費者就能拿到需要處理的數(shù)據(jù)進行處理了。那每個消費者又是怎么記錄自己消費的位置呢?在早期的版本中,消費者將消費到的offset維護zookeeper中,consumer每間隔一段時間上報一次,這里容易導(dǎo)致重復(fù)消費,且性能不好!在新的版本中消費者消費到的offset已經(jīng)直接維護在kafk集群的__consumer_offsets這個topic中!
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/129117.html