kafka高吞吐,低延遲的分佈式消息隊列

核心概念

  • 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

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

API

生產者

 

消費者

 

數據丟失和重複讀取

生產者消息丟失

緣由1:kafka數據先存儲在內存中,一段時間後溢寫到硬盤中。那麼節點宕機,在內存中的消息未持久化,隨着內存一塊兒丟失。

緣由2:分區主從備份,leader分區宕機,從分區未及時拉取同步,致使數據丟失

處理方式:修改持久化觸發參數(數據量,時間)

處理方式:修改。。。。

消息丟失(消費者)

緣由:在High level模式下,客戶端向zk提交了偏移量,但數據讀取時消費節點掛了,致使偏移量以前的數據沒處理完畢。消費節點再次上線,從zk獲取偏移量並向後讀取,以前的數據再也不處理,最終致使消費數據的丟失。

解決:客戶端每條消息處理完,再手動提交偏移量,關閉偏移量自動提交。

重複消費(消費者)

緣由:數據處理完之後,偏移量自動提交,設置間隔時間較長。節點宕機後,獲取的偏移量是前一次的,節點會重複執行已執行的消息。

解決:手動提交數偏移量

高吞吐

高吞量

  • pagecache(頁緩存),基於系統內存的數據接收

  • 磁盤順序寫,相對隨機存效率百倍以上,尤爲對於磁盤存儲。

高吐量

  • 零拷貝計數

    pagecache -- 網卡bufffer(數據)+socket(描述符)-- 客戶端

高吞吐

  • producer消息存入速度與consumer讀取數據速度維持均衡,保證在數據flush到磁盤前讀取數據,實現只在pagecache內存層面的隊列高速吞吐。

相關文章
相關標籤/搜索