Kafka是由Apache軟件基金會開發的一個開源流處理平臺,由Scala和Java語言編寫。Kafka是一種高吞吐量的分佈式發佈-訂閱消息系統,它能夠處理消費者在網站中的全部動做流數據。 這種動做(網頁瀏覽,搜索和其餘用戶的行動)是在現代網絡上的許多社會功能的一個關鍵因素。 這些數據一般是因爲吞吐量的要求而經過處理日誌和日誌聚合來解決。 對於像Hadoop同樣的日誌數據和離線分析系統,但又要求實時處理的限制,這是一個可行的解決方案。nginx
Kafka的目的是經過Hadoop的並行加載機制來統一線上和離線的消息處理,也是爲了經過集羣來提供實時的消息。kafka是用於構建實時數據管道和流應用程序。具備橫向擴展、容錯、快速等優勢,並已在成千上萬家公司運行。和redis、rabbitmq等消息中間件同樣,Apache kafka也是消息中間件的一種,只是每一個消息中間件的定位不太相同,適用場景也不太一致。web
Kafka是最初由Linkedin公司開發,是一個分佈式、支持分區的(partition)、多副本的(replica)、基於zookeeper協調的分佈式消息系統,它最大的特性就是能夠實時的處理大量數據以知足各類需求場景:好比基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎、web/nginx日誌、訪問日誌、消息服務等。Linkedin於2010年貢獻給了Apache基金會併成爲頂級開源項目。redis
主要應用場景以下:
(1)消息系統
Kafka能夠做爲傳統消息系統的替代。相比傳統消息系統,Kafka有更高的吞吐量、擁有內置的分區Partition、複製備份高容錯能力。傳統消息系統對高吞吐量沒有太高要求,但kafka的低延遲特性和強大的備份容錯能力是傳統消息所必須的。服務器
(2)網站行爲追蹤
Kafka可用於用戶行爲追蹤,經過將用戶行爲數據發送給Kafka,以此爲基礎,實現用戶行爲在線與離線分析,可用於網站實時監控與異常行爲攔截等。網絡
(3)日誌收集
Kafka能夠做爲日誌收集解決方案。日誌收集一般是將不一樣服務器的日誌文件收集到一箇中心區域,Kafka實現了對日誌文件數據進行抽象,統一了處理接口。Kafka低延遲,支持不一樣的日誌數據源,分佈式消費易於擴展,可同時將數據提供給hdfs、storm、監控軟件等等。架構
(4)應用監控
Kafka可用於監控運行中的應用系統。如收集分佈式應用的數據進行聚合計算,進行分析檢測異常狀況。異步
須要注意如下三點:分佈式
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統,它專爲分佈式高吞吐量系統而設計。與其餘消息傳遞系統相比,Kafka具備更好的吞吐量,內置分區,複製和固有的容錯能力,這使得它很是適合大規模消息處理應用程序。
具備以下特性:
(1)以時間複雜度爲O(1)的方式提供消息持久化能力,即便對TB級以上數據也能保證多數時間的訪問性能。
(2)高吞吐量:即便在很是廉價的商用機器上也能作到單機支持每秒百萬條消息的傳輸。
(3)支持Kafka Server間的消息分區及分佈式消費,同時保證每一個partition(分區)內的消息順序傳輸。
(4)同時支持離線數據處理和實時數據處理。
(5)支持Hadoop並行數據加載。
(6)Scale out:支持在線水平擴展。
Kafka將消息保留在磁盤上,並在羣集內複製以防止數據丟失。 Kafka構建在ZooKeeper同步服務之上。它與Apache Storm和Spark很是好地集成,用於實時流式數據分析。ide
一個消息系統負責將數據從一個應用傳遞到另一個應用,應用只需關注於數據,無需關注數據在兩個或多個應用間是如何傳遞的。分佈式消息傳遞基於可靠的消息隊列,在客戶端應用和消息系統之間異步傳遞消息。有兩種主要的消息傳遞模式:點對點傳遞模式、發佈-訂閱模式。大部分的消息系統選用發佈-訂閱模式。Kafka就是一種發佈-訂閱模式。oop
(1)點對點消息傳遞模式
在點對點消息系統中,消息持久化到一個隊列中。此時,將有一個或多個消費者消費隊列中的數據。可是一條消息只能被消費一次。當一個消費者消費了隊列中的某條數據以後,該條數據則從消息隊列中刪除。該模式即便有多個消費者同時消費數據,也能保證數據處理的順序。這種架構描述示意圖以下:
(2)發佈-訂閱消息傳遞模式
在發佈-訂閱消息系統中,消息被持久化到一個topic中。與點對點消息系統不一樣的是,消費者能夠訂閱一個或多個topic,消費者能夠消費該topic中全部的數據,同一條數據能夠被多個消費者消費,但數據被消費後不會立馬刪除,數據保留是期限的,默認是7天,由於他不是存儲系統。
kafka有兩種方式,一種是是消費者去主動去消費(拉取)消息,而不是生產者推送消息給消費者;另一種就是生產者主動推送消息給消費者,相似公衆號。
在發佈-訂閱消息系統中,消息的生產者稱爲發佈者,消費者稱爲訂閱者。該模式的示例圖以下:
kafka中最重要的幾個關鍵術語及其關係以下圖所示:
上圖中一個topic配置了3個partition。Partition1有兩個offset:0和1。Partition2有4個offset。Partition3有1個offset。副本的id和副本所在的機器的id剛好相同。若是一個topic的副本數爲3,那麼Kafka將在集羣中爲每一個partition建立3個相同的副本。集羣中的每一個broker存儲一個或多個partition。多個producer和consumer可同時生產和消費數據。
(1)術語之broker
Kafka集羣包含一個或多個服務器,這種服務器被稱爲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集羣數據不均衡。
(2)術語之Topic
每條發佈到Kafka集羣的消息都有一個類別,這個類別被稱爲Topic。(物理上不一樣Topic的消息分開存儲,邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處),Topic即主題,經過對消息指定主題能夠將消息分類,消費者能夠只關注本身須要的Topic中的消息。
屬於特定類別的消息流稱爲主題。數據存儲在主題中,Topic至關於Queue。主題被拆分紅分區,每一個這樣的分區包含不可變有序序列的消息,分區被實現爲具備相等大小的一組分段文件。
(3)術語之Partition
Partition(分區)是物理上的概念,每一個Topic包含一個或多個Partition。每一個topic至少有一個partition。每一個partition中的數據使用多個segment文件存儲。任何發佈到此Partition的消息都會被追加到Log文件的尾部,在分區中的每條消息都會按照時間順序分配到一個單調遞增的順序編號,也就是咱們的Offset,Offset是一個Long型的數字。咱們經過這個Offset能夠肯定一條在該Partition下的惟一消息,在Partition下面是保證了有序性,可是在Topic下面沒有保證有序性。以下圖所示:
Partition offset(分區偏移):每一個分區消息具備稱爲offset的惟一序列標識。
Replicas of partition(分區備份):副本只是一個分區的備份。 副本從不讀取或寫入數據。 它們主要用於防止數據丟失。
在每一個分區中,消息以順序存儲,最晚接收的消息會最後被消費。
(4)術語之Producer
生產者即數據的發佈者,該角色將消息發佈到Kafka的topic中。broker接收到生產者發送的消息後,broker將該消息追加到當前用於追加數據的segment文件中。生產者在向kafka集羣發送消息的時候,能夠經過指定分區來發送到指定的分區中,也能夠經過指定均衡策略來將消息發送到不一樣的分區中;若是不指定,就會採用默認的隨機均衡策略,將消息隨機的存儲到不一樣的分區中。
(5)術語之Consumer
Consumer即消費者,消費者經過與kafka集羣創建長鏈接的方式,不斷地從集羣中拉取消息,而後能夠對這些消息進行處理。消費者能夠消費多個topic中的數據。
(6)術語之Consumer Group
每一個Consumer屬於一個特定的Consumer Group(可爲每一個Consumer指定group name,若不指定group name則屬於默認的group)。
在消費者消費消息時,kafka使用offset來記錄當前消費的位置。在kafka的設計中,能夠有多個不一樣的group同時消費同一個topic下的消息,以下圖所示,
咱們有兩個不一樣的group同時消費同一個topic中的消息,他們消費的記錄位置offset各不項目,不互相干擾。
對於一個group而言,消費者的數量不該該多餘分區的數量,由於在一個group中,每一個分區至多隻能綁定到一個消費者上,即一個消費者能夠消費多個分區,一個分區只能給一個消費者消費。所以,若一個group中的消費者數量大於分區數量的話,多餘的消費者將不會收到任何消息。
(7)術語之Leader
每一個partition有多個副本,其中有且僅有一個做爲Leader,Leader是當前負責數據的讀寫的partition。
(8)術語之FollowerFollower跟隨Leader,全部寫請求都經過Leader路由,數據變動會廣播給全部Follower,Follower與Leader保持數據同步。若是Leader失效,則從Follower中選舉出一個新的Leader。當Follower與Leader掛掉、卡住或者同步太慢,leader會把這個follower從「in sync replicas」(ISR)列表中刪除,從新建立一個follower。