核心概念
-
broker是kafka的節點，多台broker集群就是kafka
-
topic消息分為多個topic
-
partition分區，topic划分了多個partition分區，存在負載均衡策略
每個分區由一個個消息構成，消息在分區中被標識了遞增的序號（表明了消息的偏移量）
每個分區各自維護一套偏移量
-
producer生產者，選擇topic插入消息數據。根據kafka的分配策略，將消息插入某個分區隊尾。
-
consumer消費者，選擇topic並根據offset偏移量來獲取消息數據，記錄當前讀取的消息的偏移量，下次讀取從前一次的偏移量基礎上繼續讀取。
消費者需要自己保存偏移量，通過修改偏移量實現讀取不同位置的消息。多個消費者不會相互影響，線程安全，實現高並發消費。
-
消息數據的刪除時間默認為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內存層面的隊列高速吞吐。