Kafka系列1：Kafka概況 Kafka是當前分散式系統中最流行的消息中間件之一，憑藉著其高吞吐量的設計，在日誌收集系統和消息系統的應用場景中深得開發者喜愛。本篇就聊聊Kafka相關的一些知識點。主要包括以下內容： Kafka簡介 Kafka特點 Kafka基本概念 Kafka架構 Kafka的 ...
Kafka系列1：Kafka概況
Kafka是當前分散式系統中最流行的消息中間件之一，憑藉著其高吞吐量的設計，在日誌收集系統和消息系統的應用場景中深得開發者喜愛。本篇就聊聊Kafka相關的一些知識點。主要包括以下內容：
- Kafka簡介
- Kafka特點
- Kafka基本概念
- Kafka架構
- Kafka的幾個核心概念
- 分區Partition
- 複製Replication
- 消息發送
- 消費者組
- 消費偏移量
- Kafka的工程應用
Kafka簡介
Kafka特點
Kafka是最初由Linkedin公司開發，是一個分散式、分區的、多副本的、多訂閱者，基於zookeeper協調的分散式日誌系統（也可以當做MQ系統），常見可以用於web/nginx日誌、訪問日誌，消息服務等等，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源項目。相比於其他的消息隊列中間件，Kafka的主要設計目標，也即其特點如下：
- 以時間複雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間的訪問性能。
- 高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸。
- 支持Kafka Server間的消息分區，及分散式消費，同時保證每個partition內的消息順序傳輸。
- 同時支持離線數據處理和實時數據處理。
- Scale out:支持線上水平擴展
Kafka基本概念
- Kaka集群中的一臺或多台伺服器稱為Broker。Broker存儲Topic的數據。
- 如果某topic有N個partition，集群有N個broker，那麼每個broker存儲該topic的一個partition。
- 如果某topic有N個partition，集群有(N+M)個broker，那麼其中有N個broker存儲該topic的一個partition，剩下的M個broker不存儲該topic的partition數據。
- 如果某topic有N個partition，集群中broker數目少於N個，那麼一個broker存儲該topic的一個或多個partition。在實際生產環境中，儘量避免這種情況的發生，這種情況容易導致Kafka集群數據不均衡。
- 發佈到Kafka的每條消息都有一個類別，是個邏輯概念。
- 物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上，但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處
- 物理上的Topic分區，一個Topic可以分為多個Partition，至少有一個Partition。
- 每個Partition中的數據使用多個segment文件存儲，每個Partition都是一個有序的隊列，不同Partition間的數據是無序的。
- Partition中的每條消息都會被分配一個有序的ID（即offset）。
- 消息和數據的生產者。Producer將消息發佈到Kafka的topic中。
- Broker接收到Producer發佈的消息後，Broker將該消息追加到當前用於追加數據的segment文件中。
- Producer發送的消息，存儲到一個Partition中，Producer也可以指定數據存儲的Partition。
- 消息和數據的消費者。Consumer從Broker中讀取數據。
- Consumer可以消費多個topic中的數據。
- 每個消費者都屬於一個特定的消費者組。
- 可為每個Consumer指定group name，若不指定group name則屬於預設的group。
- 一個Topic可以有多個消費者組，Topic的消息會被覆制到所有的消費者組中，但每個消費者組只會把消息發送給該組中的一個消費者。
- 消費者組是Kafka用來實現一個Topic消息的廣播和單播的手段。
- 每個Partition有多個副本，其中有且僅有一個作為leader。
- Leader是當前負責數據的讀寫的Partition。
- Follower跟隨Leader，所有寫請求都通過Leader路由，數據變更會廣播給所有Follower，Follower與Leader保持數據同步。
- 如果Leader失效，則從Follower中選舉出一個新的Leader。
- 如果Follower與Leader掛掉、卡住或同步太慢，Leader會把這個Follower從"in sync replicas"## 高吞吐量的分散式消息組件Kafka是如何工作的
Kafka是當前分散式系統中最流行的消息中間件之一，憑藉著其高吞吐量的設計，在日誌收集系統和消息系統的應用場景中深得開發者喜愛。本篇就聊聊Kafka相關的一些知識點。主要包括以下內容：
- Kafka簡介
- Kafka特點
- Kafka基本概念
- Kafka架構
- Kafka的幾個核心概念
- 分區Partition
- 複製Replication
- 消息發送
- 消費者組
- 消費偏移量
- Kafka的工程應用
Kafka簡介
Kafka特點
Kafka是最初由Linkedin公司開發，是一個分散式、分區的、多副本的、多訂閱者，基於zookeeper協調的分散式日誌系統（也可以當做MQ系統），常見可以用於web/nginx日誌、訪問日誌，消息服務等等，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源項目。相比於其他的消息隊列中間件，Kafka的主要設計目標，也即其特點如下：
- 以時間複雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間的訪問性能。
- 高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸。
- 支持Kafka Server間的消息分區，及分散式消費，同時保證每個partition內的消息順序傳輸。
- 同時支持離線數據處理和實時數據處理。
- Scale out:支持線上水平擴展
Kafka基本概念
- Kaka集群中的一臺或多台伺服器稱為Broker。Broker存儲Topic的數據。
- 如果某topic有N個partition，集群有N個broker，那麼每個broker存儲該topic的一個partition。
- 如果某topic有N個partition，集群有(N+M)個broker，那麼其中有N個broker存儲該topic的一個partition，剩下的M個broker不存儲該topic的partition數據。
- 如果某topic有N個partition，集群中broker數目少於N個，那麼一個broker存儲該topic的一個或多個partition。在實際生產環境中，儘量避免這種情況的發生，這種情況容易導致Kafka集群數據不均衡。
- 發佈到Kafka的每條消息都有一個類別，是個邏輯概念。
- 物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上，但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處
- 物理上的Topic分區，一個Topic可以分為多個Partition，至少有一個Partition。
- 每個Partition中的數據使用多個segment文件存儲，每個Partition都是一個有序的隊列，不同Partition間的數據是無序的。
- Partition中的每條消息都會被分配一個有序的ID（即offset）。
- 消息和數據的生產者。Producer將消息發佈到Kafka的topic中。
- Broker接收到Producer發佈的消息後，Broker將該消息追加到當前用於追加數據的segment文件中。
- Producer發送的消息，存儲到一個Partition中，Producer也可以指定數據存儲的Partition。
- 消息和數據的消費者。Consumer從Broker中讀取數據。
- Consumer可以消費多個topic中的數據。
- 每個消費者都屬於一個特定的消費者組。
- 可為每個Consumer指定group name，若不指定group name則屬於預設的group。
- 一個Topic可以有多個消費者組，Topic的消息會被覆制到所有的消費者組中，但每個消費者組只會把消息發送給該組中的一個消費者。
- 消費者組是Kafka用來實現一個Topic消息的廣播和單播的手段。
- 每個Partition有多個副本，其中有且僅有一個作為leader。
- Leader是當前負責數據的讀寫的Partition。
- Follower跟隨Leader，所有寫請求都通過Leader路由，數據變更會廣播給所有Follower，Follower與Leader保持數據同步。
- 如果Leader失效，則從Follower中選舉出一個新的Leader。
- 如果Follower與Leader掛掉、卡住或同步太慢，Leader會把這個Follower從"in sync replicas"列表中刪除，重新創建一個Follower。
Kafka架構
Kafka一般以集群方式來部署，一個典型的Kafka集群架構如下圖所示：
Kafka的幾個核心概念
分區Partition
- 分區是Kafka的基本存儲單元，在一個Topic中會有一個或多個Partition，不同的Partition可位於不同的伺服器節點上，物理上一個Partition對應於一個文件夾。
- Partition內包含一個或多個Segment，每個Segment又包含一個數據文件和一個與之對應的索引文件。
- 對於寫操作，每次只會寫Partition內的一個Segment；對於讀操作，也只會順序讀取同一個Partition內的不同Segment。
- 邏輯上，可以把Partition當做一個非常長的數組，使用時通過這個數組的索引（offset）訪問數據。
- 由於不同的Partition可位於不同的機器上，因此可以實現機器間的並行處理。
- 由於一個Partition對應一個文件夾，多個Partition也可位於同一臺伺服器上，這樣就可以在同一臺伺服器上使不同的Partition對應不同的磁碟，實現磁碟間的並行處理。
- 故一般通過增加Partition的數量來提高系統的並行吞吐量，但也會增加輕微的延遲。
但以下這幾種情況需要註意：
- 當一個Topic有多個消費者時，一個消息只會被一個消費者組裡的一個消費者消費；
- 由於消息是以Partition為單位分配的，在不考慮Rebalance時，同一個Partition的數據只會被一個消費者消費，所以如果消費者的數量多於Partition的數量，就會存在部分消費者不能消費該Topic的情況，此時再增加消費者並不能提高系統的吞吐量；
- 在生產者和Broker的角度，對不同Partition的寫操作是完全並行的，可是對於消費者其併發數則取決於Partition的數量。實際中配置的Partition數量需要根據所設計的系統吞吐量來推算。
複製
- leader副本：每個分區都會有，所有生產者和消費者的請求都會經過leader；
- follower副本：不處理客戶端的請求，它的職責是從leader處複製消息數據，使自己和leader的狀態保持一致；
- 如果leader節點宕機，那麼某個follower就會被選為leader繼續對外提供服務；
- 複製因數：一個分區有幾個副本。
消息發送方式
從生產者的角度來看，消息發送到Broker有三種方式：
- 立即發送：只發送消息，不關心消息發送的結果。本質上也是一種非同步發送的方式，消息先存儲在緩衝區中，達到設定條件後批量發送。當然這是kafka吞吐量最高的一種方式,並配合參數acks=0，這樣生產者不需要等待伺服器的響應，以網路能支持的最大速度發送消息。但是也是消息最不可靠的一種方式，因為對於發送失敗的消息沒有做任何處理。
- 同步發送：生產者發送消息後獲取返回的Future對象，根據該對象的結果查看發送是否成功。如果業務要求消息必須是按順序發送的，那麼可以使用同步的方式，並且只能在一個partation上，結合參數設置retries的值讓發送失敗時重試，設置max_in_flight_requests_per_connection=1，可以控制生產者在收到伺服器晌應之前只能發送1個消息，在消息發送成功後立刻flush，從而控制消息順序發送。
- 非同步發送：生產者發送消息時將註冊的回調函數作為入參傳入，生產者接收到Kafka伺服器的響應時會觸發執行回調函數。如果業務需要知道消息發送是否成功，並且對消息的順序不關心，那麼可以用非同步+回調的方式來發送消息，配合參數retries=0，並將發送失敗的消息記錄到日誌文件中。
消息發送確認
消息發送到Broker後怎麼算投遞成功呢，Kafka有三種確認模式：
- 不等Broker確認就認為投遞成功；
- 由leader來確認投遞成功；
- 由所有的leader和follower都確認才認為是成功的。
三種模式對比的話，性能依次降低，但可靠性依次提高。
消息重發機制
當從Broker接收到的是臨時可恢復的異常時，生產者會向Broker重發消息，重發次數的限制值由初始化生產者對象的retries屬性決定，在預設情況下生產者會在重試後等待100ms，可以通過retry.backoff.ms屬性進行修改。
批次發送
當有多條消息要被髮送到同一個分區時，生產者會把它們放到同一個批次里，Kafka通過批次的概念來提高吞吐量，但同時也會增加延遲。對批次的控制主要通過構建生產者對象時的兩個屬性來實現：
- batch.size：當發往每個分區的緩存消息數量達到這個數值時，就會觸發一次網路請求，批次里的所有消息都會被髮送出去；
- linger.ms：每條消息在緩存中的最長時間，如果超過這個時間就會忽略batch.size的限制，由客戶端立即把消息發送出去。
消費者組
消費者組是Kafka提供的可擴展且具有容錯性的消費機制，在一個消費者組內可以有多個消費者，它們共用一個唯一標識，即分組ID。組內的所有消費者協調消費它們訂閱的主題下的所有分區的消息，但一個分區只能由同一個消費者組裡的一個消費者來消費。
廣播和單播
一個Topic可以有多個消費者組，Topic的消息會被覆制到所有的消費者組中，但每個消費者組只會把消息發送給一個消費者組裡的某一個消費者。如果要實現廣播，只需為每個消費者都分配一個單獨的消費者組介面如果要實現單播，則需要把所有的消費者都設置在同一個消費者組裡
再均衡
消費者組裡有新消費者加入或者有消費者離開，分區所有權會從一個消費者轉移到另一個消費者再均衡協議規定了一個消費者組下的所有消費者如何達成一致來分配主題下的每個分區觸發再均衡的場景有三種：
- 一是消費者組內成員發生變更
- 二是訂閱的主題數量發生表更
- 三是訂閱主題的分區數量發生變更
消費偏移量
Kafka中有一個叫作_consumer_offset特殊主題用來保存消息在每個分區的偏移量，消費者每次消費時都會往這個主題中發送消息，消息包含每個分區的偏移量。如果消費者一直處於運行狀態，偏移量沒什麼作用；如果消費者崩潰或者有新的消費者加入消費者組從而觸發再均衡操作，再均衡之後該分區的消費者若不是之前的那個，提交偏移量就有用了。維護消息偏移量對於避免消息被重覆消費和遺漏消費，確保消息的ExactlyOnce至關重要，以下是不同的提交偏移量的方式：
- 自動提交：Kafka預設會定期自動提交偏移量，提交的時間間隔預設是5秒。此方式會產生重覆處理消息的問題；
- 手動提交：在進行手動提交之前需要先關閉消費者的自動提交配置，然後用commitSync方法來提交偏移量。處理完記錄後由開發者確保調用了commitSync方法，來減少重覆處理消息的數量，但可能降低消費者的吞吐量；
- 非同步提交：使用commitASync方法來提交最後一個偏移量。消費者只管發送提交請求，而不需要等待Broker的立即回應。
Kafka的工程應用
Kafka主要用於三種場景：
- 基於Kafka的用戶行為數據採集
- 基於Kafka的日誌收集
- 基於Kafka的流量削峰
基於Kafka的用戶行為數據採集
要獲取必要的數據進行用戶行為等的分析，需要這樣幾個步驟：
- 前端數據（埋點）上報
- 接收前端數據請求
- 後端通過Kafka消費消息，必要時落庫
- 分析用戶行為
基於Kafka的日誌收集
各個應用系統在輸出日誌時利用高吞吐量的Kafka作為數據緩衝平臺，將日誌統一輸出到Kafka，再通過Kafka以統一介面服務的方式開放給各種消費者。做統一日誌平臺的方案，收集重要系統的日誌集中到Kafka中，然後再導入ElasticSearch、HDFS、Storm等具體日誌數據的消費者中，用於進行實時搜索分析、離線統計、數據備份、大數據分析等。
基於Kafka的流量削峰
為了讓系統在大流量場景下仍然可用，可以在系統中的重點業務環節加入消息隊列作為消息流的緩衝，從而避免短時間內產生的高流量帶來的壓垮整個應用的問題。
關註我的公眾號，獲取更多關於面試、技術的文章及福利資源。
