kafka原理解析

kafka是大家比較常用的訊息中介軟體，本文主要介紹kafka基本元件及其相關原理

kafka通過offset保證訊息在分區內的順序，offset的順序性不跨分割槽 kafka0.10以後，使用乙個專門的topic __consumer_offset儲存offset __consumer_offset日誌留存方式為compact，也就是說，該topic會對key相同的訊息進行整理

__consumer_offset內儲存三類訊息：每個partition其實都會對應乙個日誌目錄：-/，在目錄下面會對應多個日誌分段(logsegment)。logsegment檔案由兩部分組成，分別為「.index」檔案和「.log」檔案

索引檔案使用稀疏索引的方式，避免對日誌每條資料建索引，節省儲存空間

使用page cache順序讀檔案，作業系統可以預讀資料到 page cache 使用mmap直接將日誌檔案對映到虛擬位址空間

零拷貝：訊息資料直接從 page cache 傳送到網路通常的檔案讀取需要經歷下圖的流程，有兩次使用者態與核心態之間記憶體的拷貝

kafka使用零拷貝，避免訊息在核心態和使用者態間的來回拷貝

副本同步流程：

controller類似於集群的master，主要管理如下幾塊：

controller通過broker搶占zk臨時節點擊舉出來，且controller與所有broker建立長連線

controller管理partition leader選舉，主要有以下幾種方式：

選舉方式

說明offlinepartitionleaderselector

leader 掉線時觸發

reassignedpartitionleaderselector

分割槽的副本重新分配資料同步完成後觸發的

preferredreplicapartitionleaderselector

最優 leader 選舉，手動觸發或自動 leader 均衡排程時觸發

controlledshutdownleaderselector

broker 傳送 shutdown 請求主動關閉服務時觸發

問題：

解決方案：

kafka rebalance發生的5種情況：

有新的消費者加入consumer group。

有消費者宕機下線。消費者並不一定需要真正下線，例如遇到長時間的gc、網路延遲導致消費者長時間未向groupcoordinator傳送heartbeatrequest時，groupcoordinator會認為消費者下線。

有消費者主動退出consumer group。

consumer group訂閱的任一topic出現分割槽數量的變化。

消費者呼叫unsubscrible()取消對某topic的訂閱。

kafka通過groupcoordinator管理rebalance操作

join group:

consumer首先向groupcoordinator傳送joingrouprequest請求，其中包含消費者的相關資訊

groupcoordinator從中選取乙個消費者成為group leader，封裝成joingroupresponse返回給每個消費者

只有group leader收到的joingroupresponse中封裝了所有消費者的資訊， group leader根據消費者的資訊以及選定的分割槽分配策略進行分割槽分配。

sync group: