快速瞭解 Kafka 基礎架構

今天來聊下大數據場景下比較流行的消息隊列組件kafka。本篇文章將主要從理論角度來介紹。

kafka是一款開源、追求高吞吐、實時性，可持久化的流式消息隊列，可同時處理在線（消息）與離線應用(業務數據和日誌)。在現在火熱的大數據時代，獲得了普遍的應用。

總體架構

kafka的消息以Topic進行歸類，支持分佈式distribution、可分區partition和可複製replicated的特性。下面爲本人梳理的一張Kafka系統架構圖。

Kafka的架構相較於其餘消息系統而言，比較簡單。其總體流程簡述以下

Producer與指定Topic各分區Partition的Leader鏈接，從而將消息push到Broker中。
Broker可理解消息系統的中間代理，將消息寫入磁盤實現持久化，並可對消息複製備份。
Consumer採用pull的方式主動獲取broker中指定Topic的消息，並進行處理。
Zookeeper負責Kafka服務相關metadata的存儲，如broker，topic和consumer等信息的存儲。

注：zookeeper是一個分佈式協調服務，分佈式應用可基於它實現同步服務，配置維護和命名服務等。此篇文章不作介紹，之後有時間再作總結！

下面對涉及的各個組件做詳細介紹。

主題Topic

首先，Kafka中的消息以Topic分類管理。在Kafka中，一個topic可被多個Consumer訂閱。經過集羣管理，每一個Topic可由多個Partition組成。以下圖

從上圖能夠看出，Topic中數據是順序不可變序列，採用log追加方式寫入，於是kafka中無因隨機寫入致使性能低下的問題。

Topic的數據可存儲在多個partition中，便可存放在不一樣的服務器上。這可以使Topic大小不限於一臺server容量。同時，消息存在多個partition上，能夠實現Topic上消息的併發訪問。

Kafka中數據不會因被consumer消費後而丟失，而是經過配置指定消息保存時長。Topic中每一個partition中的消息都有一個惟一的標識，也稱爲offset。因數據不會因消費而丟失，因此只要consumer指定offset，一個消息可被不一樣的consumer屢次消費。

基於此，消息獲取便可採用順序訪問，咱們也能夠指定任意offset隨機訪問，且不會對其餘consumer產生影響。

分佈式Distribution

Kafka的集羣分佈式主要涉及兩個內容：Partition分區與Replication備份。

Partition實現將Topic中的各個消息存儲到不一樣的分區中，從而分佈在不一樣的Kafka節點之上，使Topic的數據大小不限於一臺Server。

Replication主要用於容錯，對一個Partition複製多份，存儲在不一樣kafka節點上。這可防止因某一分區數據丟失而致使錯誤。

雖然Relication複製Partition多份，但其中只有一個爲Leader角色，其他Partition角色皆爲Follower。Producer發佈消息都是由Leader負責寫入，並同步到其餘的Follower分區中。若是Leader失效，則某個Follower會自動替換，成爲新的Leader分區。此時，Follower可能落後於Leader，因此從全部Follower中選擇一個」up-to-date」的分區。

關於性能方面，考慮Leader不但承載了客戶的鏈接與消息寫入，還負責將消息同步至不一樣的Follower分區上，性能開銷較大。所以，不一樣Partition的Leader分佈在不一樣的kafka節點上，從而防止某個節點壓力過載。

爲了更好了解Partition與Replication關係。舉個例子，假設現有一個Topic名爲spark_topic，其Partition分區數量爲3，Replication備份因子爲2。則效果以下圖

spark_topic存在spark_topic-1，spark_topic-2，spark_topic-3共三個分區。而每一個分區均有兩處備份，如spark_topic-1，其同時存在於kafka節點broker0與broker1上，其中broker01上的分區角色爲Leader。

消費者Consumer

Consumer負責消費消息。Kafka中Consumer消費消息採用fetch方式主動拉取，這種方式的好處是Consumer客戶端能根據本身的處理消息能力決定消息獲取的速度與批量獲取的數量，從而防止系統過載。

Kafka的消息並不會由於消息被Consumer消費而丟失，於是其提供一個惟一的標識offset實現消息的順序獲取，而offset須要consumer自行維護，非kafka節點服務管理。這不一樣於傳統的消息系統。在Kafka集羣中，消費者的信息與offset在zookeeper也有保存維護，Consumer會間歇性向zookeeper同步offset。

Kafka的Consumer提供分組功能，每一個Consumer都屬於一個分組。那分組的做用是什麼呢？

相似queue模式，一個Consumer分組的多個Consumer訂閱同一個Topic，一條消息只分發給其中一個Consumer，實現負載均衡效果。

發佈訂閱模式，而不一樣組的多個Consumer訂閱同一個Topic，一條消息會廣播給在不一樣分組的全部Consumer。

請注意，在Kafka中，同一Consumer分組中，一個Consumer只能訂閱一個Topic中的Partition，於是在一個Consumer分組中，同時訂閱同一個Topic的Consumer的個數不能超過Partition分區數。可參看上圖所示。

一樣，爲減小網絡IO開銷，Consumer可採用batch fetch方式實現一次批量獲取多條消息。

應用場景

下面是一些官網介紹的Kafka應用場景，包括消息系統、網站行爲跟蹤、應用監控、日誌收集等等。

消息系統

Kafka能夠做爲傳統消息系統的替代。相比傳統消息，Kafka有更高的吞吐量、擁有內置的分區Partition、複製備份高容錯能力。

傳統消息系統對高吞吐量沒有太高要求，但kafka的低延遲特性和強大的備份容錯能力是傳統消息所必須的。

網站行爲追蹤

Kafka可用於用戶行爲追蹤，經過將用戶行爲數據發送給Kafka。以此爲基礎，實現用戶行爲在線與離線分析，可用於網站實時監控與異常行爲攔截等。

日誌收集

Kafka能夠做爲日誌收集解決方案。日誌收集一般是將不一樣服務器的日誌文件收集到一箇中心區域，Kafka實現了對日誌文件數據進行抽象，統一了處理接口。Kafka低延遲，支持不一樣的日誌數據源，分佈式消費易於擴展，可同時將數據提供給hdfs、storm、監控軟件等等。

應用監控

Kafka可用於監控運行中的應用系統。如收集分佈式應用的數據進行聚合計算，進行分析檢測異常狀況。

我的感受，本質和網站行爲分析異常監控有殊途同歸之處，只不過所監控的數據對象不一樣罷了。

結束

利用兩週末學習總結了大數據中經常使用的消息隊列服務-Kafka。本篇主要從架構角度介紹。我的感受，介紹系統架構比操做實戰更加困難，文章若有錯誤，請幫忙請指正。