Kafka整體介紹

Kafka整體介紹

背景介紹

 

kafka是最初由Linkedin公司開發，使用Scala語言編寫，Kafka是一個分佈式、分區的、多副本的、多訂閱者的日誌系統(分佈式MQ系統)，能夠用於web/nginx日誌，搜索日誌，監控日誌，訪問日誌等等。

 

kafka目前支持多種客戶端語言：java，python，c++，php等等。

 

 

 

kafka名詞解釋和工做方式：

 

Producer ：消息生產者，就是向kafka broker發消息的客戶端。

Consumer ：消息消費者，向kafka broker取消息的客戶端

Topic ：消息主題。

Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給全部的consumer）和單播（發給任意一個consumer）的手段。一個topic能夠有多個CG。topic的消息會複製（不是真的複製，是概念上的）到全部的CG，但每一個CG只會把消息發給該CG中的一個consumer。若是須要實現廣播，只要每一個consumer有一個獨立的CG就能夠了。要實現單播只要全部的consumer在同一個CG。用CG還能夠將consumer進行自由的分組而不須要屢次發送消息到不一樣的topic。

Broker ：一臺kafka服務器就是一個broker。一個集羣由多個broker組成。一個broker能夠容納多個topic。

Partition：爲了實現擴展性，一個很是大的topic能夠分佈到多個broker（即服務器）上，一個topic能夠分爲多個partition，每一個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的總體（多個partition間）的順序。

 Offset：kafka的存儲文件都是按照offset.kafka來命名，用offset作名字的好處是方便查找。例如你想找位於2049的位置，只要找到2048.kafka的文件便可。固然the first offset就是00000000000.kafka

 

kafka特性：（後面建議從新修改，寫的比較抽象）

l  經過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即便數以TB的消息存儲也可以保持長時間的穩定性能。

l  高吞吐量：即便是很是普通的硬件kafka也能夠支持每秒數十萬的消息。

l  支持同步和異步複製兩種HA

l  Consumer客戶端pull，隨機讀,利用sendfile系統調用，zero-copy ,批量拉數據

l  消費狀態保存在客戶端

l  消息存儲順序寫

l  數據遷移、擴容對用戶透明

l  支持Hadoop並行數據加載。

l  支持online和offline的場景。

l  持久化：經過將數據持久化到硬盤以及replication防止數據丟失。

l  scale out：無需停機便可擴展機器。

l  按期刪除機制，支持設定partitions的segment file保留時間。

 

可靠性（一致性)

kafka(MQ)要實現從producer到consumer之間的可靠的消息傳送和分發。傳統的MQ系統一般都是經過broker和consumer間的確認（ack）機制實現的，並在broker保存消息分發的狀態。

 

即便這樣一致性也是很難保證的（參考原文）。kafka的作法是由consumer本身保存狀態，也不要任何確認。這樣雖然consumer負擔更重，但其實更靈活了。

 

由於無論consumer上任何緣由致使須要從新處理消息，均可以再次從broker得到。

 

kafak系統擴展性

kafka使用zookeeper來實現動態的集羣擴展，不須要更改客戶端（producer和consumer）的配置。broker會在zookeeper註冊並保持相關的元數據（topic，partition信息等）更新。

 

而客戶端會在zookeeper上註冊相關的watcher。一旦zookeeper發生變化，客戶端能及時感知並做出相應調整。這樣就保證了添加或去除broker時，各broker間仍能自動實現負載均衡。

 

kafka設計目標

高吞吐量是其核心設計之一。

 

數據磁盤持久化：消息不在內存中cache，直接寫入到磁盤，充分利用磁盤的順序讀寫性能。

l  zero-copy：減小IO操做步驟。

l  支持數據批量發送和拉取。

l  支持數據壓縮。

l  Topic劃分爲多個partition，提升並行處理能力。

Producer負載均衡和HA機制

producer根據用戶指定的算法，將消息發送到指定的partition。

存在多個partiiton，每一個partition有本身的replica，每一個replica分佈在不一樣的Broker節點上。

多個partition須要選取出lead partition，lead partition負責讀寫，並由zookeeper負責fail over。

經過zookeeper管理broker與consumer的動態加入與離開。

Consumer的pull機制

因爲kafka broker會持久化數據，broker沒有cahce壓力，所以，consumer比較適合採起pull的方式消費數據，具體特別以下：

 

簡化kafka設計，下降了難度。

Consumer根據消費能力自主控制消息拉取速度。

consumer根據自身狀況自主選擇消費模式，例如批量，重複消費，從制定partition或位置(offset)開始消費等.

Consumer與topic關係以及機制

本質上kafka只支持Topic.每一個consumer屬於一個consumer group;反過來講,每一個group中能夠有多個consumer.對於Topic中的一條特定的消息,

只會被訂閱此Topic的每一個group中的一個consumer消費,此消息不會發送給一個group的多個consumer;那麼一個group中全部的consumer將會交錯的消費整個Topic.

若是全部的consumer都具備相同的group,這種狀況和JMS queue模式很像;消息將會在consumers之間負載均衡.

若是全部的consumer都具備不一樣的group,那這就是"發佈-訂閱";消息將會廣播給全部的消費者.

 

 

 

在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻);每一個group中consumer消息消費互相獨立;咱們能夠認爲一個group是一個"訂閱"者,

 

一個Topic中的每一個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer能夠同時消費多個partitions中的消息.

 

kafka只能保證一個partition中的消息被某個consumer消費時是順序的.事實上,從Topic角度來講,當有多個partitions時,消息仍不是全局有序的.

 

 

 

一般狀況下,一個group中會包含多個consumer,這樣不只能夠提升topic中消息的併發消費能力,並且還能提升"故障容錯"性,若是group中的某個consumer失效,

 

那麼其消費的partitions將會有其餘consumer自動接管.kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,

 

不然將意味着某些consumer將沒法獲得消息.

 

Producer均衡算法

kafka集羣中的任何一個broker,均可以向producer提供metadata信息,這些metadata中包含"集羣中存活的servers列表"/"partitions leader列表"

等信息(請參看zookeeper中的節點信息).當producer獲取到metadata信心以後, producer將會和Topic下全部partition leader保持socket鏈接;

消息由producer直接經過socket發送到broker,中間不會通過任何"路由層".事實上,消息被路由到哪一個partition上,有producer客戶端決定.

好比能夠採用"random""key-hash""輪詢"等,若是一個topic中有多個partitions,那麼在producer端實現"消息均衡分發"是必要的.

在producer端的配置文件中,開發者能夠指定partition路由的方式.

 

Consumer均衡算法

當一個group中,有consumer加入或者離開時,會觸發partitions均衡.均衡的最終目的,是提高topic的併發消費能力.

1) 假如topic1,具備以下partitions: P0,P1,P2,P3

2) 加入group中,有以下consumer: C0,C1

3) 首先根據partition索引號對partitions排序: P0,P1,P2,P3

4) 根據consumer.id排序: C0,C1

5) 計算倍數: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)

6) 而後依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]

 

kafka broker集羣內broker之間replica機制

kafka中,replication策略是基於partition,而不是topic;kafka將每一個partition數據複製到多個server上,任何一個partition有一個leader和多個follower(能夠沒有);

 

備份的個數能夠經過broker配置文件來設定.leader處理全部的read-write請求,follower須要和leader保持同步.Follower就像一個"consumer",

 

消費消息並保存在本地日誌中;leader負責跟蹤全部的follower狀態,若是follower"落後"太多或者失效,leader將會把它從replicas同步列表中刪除.

 

當全部的follower都將一條消息保存成功,此消息才被認爲是"committed",那麼此時consumer才能消費它,這種同步策略,就要求follower和leader之間必須具備良好的網絡環境.

 

即便只有一個replicas實例存活,仍然能夠保證消息的正常發送和接收,只要zookeeper集羣存活便可.(備註:不一樣於其餘分佈式存儲,好比hbase須要"多數派"存活才行)

 

 

按照當前對kafka功能模塊的理解，爲了方便學習和上手，將kafka大概劃分爲以下模塊組成，後續也會根據此模塊及消息的傳入流程依次進行介紹

 

 

 

 

 

 

 

參考：https://blog.csdn.net/lizhitao/article/details/23743821