本系列主要講解kafka基本設計和原理分析,分以下內容:html
kafka在1.0版本之前,官方主要定義爲分佈式多分區多副本的消息隊列,而1.0後定義爲分佈式流處理平臺,就是說處理傳遞消息外,kafka還能進行流式計算,相似Strom和SparkStreaming。
主要有三大核心能力:算法
能夠看到其主要分爲兩類應用,即系統或應用程序之間的數據共享,以及構建實時流應用程序並進行相應的處理。
數據庫
相關功能主要經過以下四個核心API實現:編程
kafka的主題(topic)是支持多用戶訂閱的,一個主題能夠有零個,一個或多個消費者訂閱寫入的數據。
對於每個主題,Kafka集羣保持一個分區日誌文件,看下圖:
服務器
每一個分區是一個有序的,不可變的消息序列,新的消息不斷追加,同時分區會給每一個消息記錄分配一個順序ID號 – 偏移量, 用於惟一標識該分區中的每一個記錄。併發
Kafka集羣保留全部發布的記錄,無論這個記錄有沒有被消費過,Kafka提供可配置的保留策略去刪除舊數據(還有一種策略根據分區大小刪除數據)。例如,若是將保留策略設置爲兩天,在記錄公佈後兩天,它可用於消費,以後它將被丟棄以騰出空間。Kafka的性能跟存儲的數據量的大小無關, 因此將數據存儲很長一段時間是沒有問題的。
分佈式
事實上,保留在每一個消費者元數據中的最基礎的數據就是消費者正在處理的當前記錄的偏移量(offset)或位置(position)。這種偏移是由消費者控制:一般偏移會隨着消費者讀取記錄線性前進,但事實上,由於其位置是由消費者進行控制,消費者能夠在任何它喜歡的位置讀取記錄。例如,消費者能夠恢復到舊的偏移量對過去的數據再加工或者直接跳到最新的記錄,並消費從「如今」開始的新的記錄。
數據日誌的分區,有多個目的。首先,每一個單獨的分區的大小受到承載它的服務器的限制,但一個主題可能有不少分區,容許數據可以擴展到多個服務器,以便它可以支持海量的的數據。其次,更重要的意義是分區是進行並行處理的基礎單元。
日誌的分區會跨服務器的分佈在Kafka集羣中,每一個服務器會共享分區進行數據請求的處理。每一個分區能夠配置必定數量的副本分區以提供容錯能力。
每一個分區都有一個服務器充當「leader」和零個或多個服務器充當「followers」。 leader處理全部的讀取和寫入分區的請求,而followers被動的從leader拷貝數據。若是leader失敗了,followers之一將自動成爲新的領導者。每一個服務器可能充當一些分區的leader和其餘分區的follower,這樣的負載就會在集羣內很好的均衡分配。高併發
生產者發佈數據到他們所選擇的主題。生產者負責選擇把記錄分配到主題中的哪一個分區。這可使用輪詢算法( round-robin)進行簡單地平衡負載,也能夠根據一些更復雜的語義分區算法(好比基於記錄一些鍵值自定義)來完成。性能
消費者以消費羣(consumer group )的名稱來標識本身,每一個發佈到主題的消息都會發送給訂閱了這個主題的消費羣裏面的一個消費者的一個實例。消費者的實例能夠在單獨的進程或單獨的機器上。
若是全部的消費者實例都屬於相同的消費羣,那麼記錄將有效地被均衡到每一個消費者實例。
若是全部的消費者實例有不一樣的消費羣,那麼每一個消息將被廣播到全部的消費者進程。
設計
兩個服務器的Kafka集羣具備四個分區(P0-P3)和兩個消費羣。A消費羣有兩個消費者,B羣有四個。
更常見的是,咱們會發現主題有少許的消費羣,每個都是「邏輯上的訂閱者」。每組都是由不少消費者實例組成,從而實現可擴展性和容錯性。這只不過是發佈 – 訂閱模式的再現,區別是這裏的訂閱者是一組消費者而不是一個單一的進程的消費者。
Kafka消費羣的實現方式是經過分割日誌的分區,分給每一個Consumer實例,使每一個實例在任什麼時候間點的均可以「公平分享」獨佔的分區。維持消費羣中的成員關係的這個過程是經過Kafka動態協議處理。若是新的實例加入該組,他將接管該組的其餘成員的一些分區; 若是一個實例死亡,其分區將被分配到剩餘的實例。
Kafka只保證一個分區內的消息有序,不能保證一個主題的不一樣分區之間的消息有序。分區的消息有序與依靠主鍵進行數據分區的能力相結合足以知足大多數應用的要求。可是,若是你想要保證全部的消息都絕對有序能夠只爲一個主題分配一個分區,雖然這將意味着每一個消費羣同時只能有一個消費進程在消費。
關於做者
愛編程、愛鑽研、愛分享、愛生活
關注分佈式、高併發、數據挖掘
如需捐贈,請掃碼