broker是kafka的節點,多臺broker集羣就是kafka緩存
topic消息分爲多個topic安全
partition分區,topic劃分了多個partition分區,存在負載均衡策略併發
每一個分區由一個個消息構成,消息在分區中被標識了遞增的序號(代表了消息的偏移量)負載均衡
每一個分區各自維護一套偏移量socket
producer生產者,選擇topic插入消息數據。根據kafka的分配策略,將消息插入某個分區隊尾。高併發
consumer消費者,選擇topic並根據offset偏移量來獲取消息數據,記錄當前讀取的消息的偏移量,下次讀取從前一次的偏移量基礎上繼續讀取。spa
消費者須要本身保存偏移量,經過修改偏移量實現讀取不一樣位置的消息。多個消費者不會相互影響,線程安全,實現高併發消費。線程
消息數據的刪除時間默認爲7天隊列
以partition爲單位進行備份,每一個partition設置一個leader(自己)和若干follower,隨機分配在集羣上。leader處理讀寫請求,follower不對外服務,拉取leader數據。內存
消費者組
偏移量實際屬於消費者組。用戶綁定消費者組,消費者組之間相互獨立。
一條消息在一個組內只能消費一次,組中的多個用戶不能屢次讀取這條消息
組會阻塞多用戶同時訪問一個分區
isr列表監控follower的同步狀態,isr列表由leader動態維護。
將同步狀態知足條件的follower記錄在列表中,將不知足條件的follower移出列表。
leader下線後,從isr列表中的follower中選舉新的leader
條件參數
follower的fech拉取請求間隔時間(10s)
replica.lag.time.max.ms=10000
leader與follower相差記錄數(4000)
replica.lag.max.messages=4000
生產者
消費者
緣由1:kafka數據先存儲在內存中,一段時間後溢寫到硬盤中。那麼節點宕機,在內存中的消息未持久化,隨着內存一塊兒丟失。
緣由2:分區主從備份,leader分區宕機,從分區未及時拉取同步,致使數據丟失
處理方式:修改持久化觸發參數(數據量,時間)
處理方式:修改。。。。
緣由:在High level模式下,客戶端向zk提交了偏移量,但數據讀取時消費節點掛了,致使偏移量以前的數據沒處理完畢。消費節點再次上線,從zk獲取偏移量並向後讀取,以前的數據再也不處理,最終致使消費數據的丟失。
解決:客戶端每條消息處理完,再手動提交偏移量,關閉偏移量自動提交。
緣由:數據處理完之後,偏移量自動提交,設置間隔時間較長。節點宕機後,獲取的偏移量是前一次的,節點會重複執行已執行的消息。
解決:手動提交數偏移量
高吞量
pagecache(頁緩存),基於系統內存的數據接收
磁盤順序寫,相對隨機存效率百倍以上,尤爲對於磁盤存儲。
高吐量
零拷貝計數
pagecache -- 網卡bufffer(數據)+socket(描述符)-- 客戶端
高吞吐
producer消息存入速度與consumer讀取數據速度維持均衡,保證在數據flush到磁盤前讀取數據,實現只在pagecache內存層面的隊列高速吞吐。