kafka的工作原理解析
Kafka介紹
Kafka是最初由Linkedin公司開發,是一個分散式、支援分割槽的(partition)、多副本的(replica),基於zookeeper協調的分散式訊息系統,它的最大的特性就是可以實時的處理大量資料以滿足各種需求場景:比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎,web/nginx日誌、訪問日誌,訊息服務等等,用scala語言編寫,Linkedin於2010年貢獻給了Apache基金會併成為頂級開源 專案。
一、 Kafka的特性:
- 高吞吐量、低延遲:kafka每秒可以處理幾十萬條訊息,它的延遲最低只有幾毫秒,每個topic可以分多個partition, consumer group 對partition進行consume操作。
- 可擴充套件性:kafka叢集支援熱擴充套件
- 永續性、可靠性:訊息被持久化到本地磁碟,並且支援資料備份防止資料丟失
- 容錯性:允許叢集中節點失敗(若副本數量為n,則允許n-1個節點失敗)
- 高併發:支援數千個客戶端同時讀寫
1. broker在zk中註冊
kafka的每個broker(相當於一個節點,相當於一個機器)在啟動時,都會在zk中註冊,告訴zk其brokerid,在整個的叢集中,broker.id/brokers/ids,當節點失效時,zk就會刪除該節點,就很方便的監控整個叢集broker的變化,及時調整負載均衡。
2. topic在zk中註冊
在kafka中可以定義很多個topic,每個topic又被分為很多個分割槽。一般情況下,每個分割槽獨立在存在一個broker上,所有的這些topic和broker的對應關係都有zk進行維護
3. consumer(消費者)在zk中註冊
3.1 註冊新的消費者,當有新的消費者註冊到zk中,zk會建立專用的節點來儲存相關資訊,路徑ls /consumers/{group_id}/ [ids,owners,offset],Ids:記錄該消費分組有幾個正在消費的消費者,Owmners:記錄該消費分組消費的topic資訊,Offset:記錄topic每個分割槽中的每個offset
3.2 監聽消費者分組中消費者的變化 ,監聽/consumers/{group_id}/ids的子節點的變化,一旦發現消費者新增或者減少及時調整消費者的負載均衡。
二、Kafka的使用場景
- 日誌收集:一個公司可以用Kafka可以收集各種服務的log,通過kafka以統一介面服務的方式開放給各種consumer,例如hadoop、Hbase、Solr等。
- 訊息系統:解耦和生產者和消費者、快取訊息等。
- 使用者活動跟蹤:Kafka經常被用來記錄web使用者或者app使用者的各種活動,如瀏覽網頁、搜尋、點選等活動,這些活動資訊被各個伺服器釋出到kafka的topic中,然後訂閱者通過訂閱這些topic來做實時的監控分析,或者裝載到hadoop、資料倉庫中做離線分析和挖掘。
- 運營指標:Kafka也經常用來記錄運營監控資料。包括收集各種分散式應用的資料,生產各種操作的集中反饋,比如報警和報告。
- 流式處理:比如spark streaming和storm
- 事件源
三、Kafka 生產者-消費者
訊息系統通常都會由生產者,消費者,Broker三大部分組成,生產者會將訊息寫入到Broker,消費者會從Broker中讀取出訊息,不同的MQ實現的Broker實現會有所不同,不過Broker的本質都是要負責將訊息落地到服務端的儲存系統中。具體步驟如下:
-
生產者客戶端應用程式產生訊息:
-
客戶端連線物件將訊息包裝到請求中傳送到服務端
-
服務端的入口也有一個連線物件負責接收請求,並將訊息以檔案的形式儲存起來
-
服務端返回響應結果給生產者客戶端
-
-
消費者客戶端應用程式消費訊息:
-
客戶端連線物件將消費資訊也包裝到請求中傳送給服務端
-
服務端從檔案儲存系統中取出訊息
-
服務端返回響應結果給消費者客戶端
-
客戶端將響應結果還原成訊息並開始處理訊息
-
四、Consumer與Partition的關係
- 如果consumer比partition多,是浪費,因為kafka的設計是在一個partition上是不允許併發的,所以consumer數不要大於partition數
- 如果consumer比partition少,一個consumer會對應於多個partitions,這裡主要合理分配consumer數和partition數,否則會導致partition裡面的資料被取的不均勻
- 如果consumer從多個partition讀到資料,不保證資料間的順序性,kafka只保證在一個partition上資料是有序的,但多個partition,根據你讀的順序會有不同
- 增減consumer,broker,partition會導致rebalance,所以rebalance後consumer對應的partition會發生變化
- High-level介面中獲取不到資料的時候是會block的
負載低的情況下可以每個執行緒消費多個partition。但負載高的情況下,Consumer 執行緒數最好和Partition數量保持一致。如果還是消費不過來,應該再開 Consumer 程序,程序內執行緒數同樣和分割槽數一致。
五、Kafka 與 Zookeeper
- Zookeeper 協調控制
1. 管理broker與consumer的動態加入與離開。(Producer不需要管理,隨便一臺計算機都可以作為Producer向Kakfa Broker發訊息)
2. 觸發負載均衡,當broker或consumer加入或離開時會觸發負載均衡演算法,使得一
個consumer group內的多個consumer的消費負載平衡。(因為一個comsumer消費一個或多個partition,一個partition只能被一個consumer消費)
3. 維護消費關係及每個partition的消費資訊。
- Zookeeper上的細節:
1. 每個broker啟動後會在zookeeper上註冊一個臨時的broker registry,包含broker的ip地址和埠號,所儲存的topics和partitions資訊。
2. 每個consumer啟動後會在zookeeper上註冊一個臨時的consumer registry:包含consumer所屬的consumer group以及訂閱的topics。
3. 每個consumer group關聯一個臨時的owner registry和一個持久的offset registry。對於被訂閱的每個partition包含一個owner registry,內容為訂閱這個partition的consumer id;同時包含一個offset registry,內容為上一次訂閱的offset。
關注個人技術公眾號:nick_coding1024
不定期分享最新前沿技術框架和bat大廠常用技術等,加群不定期分享行業內大牛直播講課以及獲得內退一線網際網路公司機會。