Kafka作為一個分布式的流平臺稽亏，這到底意味著什么？

我們認為缕题，一個流處理平臺具有三個關(guān)鍵能力：

發(fā)布和訂閱消息（流）截歉，在這方面，它類似于一個消息隊列或企業(yè)消息系統(tǒng)烟零。

以容錯的方式存儲消息（流）瘪松。

在消息流發(fā)生時處理它們。

什么是kakfa的優(yōu)勢锨阿？

它應(yīng)用于2大類應(yīng)用：

構(gòu)建實時的流數(shù)據(jù)管道宵睦，可靠地獲取系統(tǒng)和應(yīng)用程序之間的數(shù)據(jù)。

構(gòu)建實時流的應(yīng)用程序墅诡，對數(shù)據(jù)流進行轉(zhuǎn)換或反應(yīng)壳嚎。

要了解kafka是如何做這些事情的，讓我們從下到上深入探討kafka的能力末早。

首先幾個概念：

kafka作為一個集群運行在一個或多個服務(wù)器上烟馅。

kafka集群存儲的消息是以topic為類別記錄的。

每個消息（也叫記錄record然磷，我習慣叫消息）是由一個key郑趁，一個value和時間戳構(gòu)成。

kafka有四個核心API：

應(yīng)用程序使用Producer API發(fā)布消息到1個或多個topic（主題）姿搜。

應(yīng)用程序使用Consumer API來訂閱一個或多個topic寡润，并處理產(chǎn)生的消息捆憎。

應(yīng)用程序使用Streams API充當一個流處理器，從1個或多個topic消費輸入流梭纹，并生產(chǎn)一個輸出流到1個或多個輸出topic躲惰，有效地將輸入流轉(zhuǎn)換到輸出流。

Connector API允許構(gòu)建或運行可重復(fù)使用的生產(chǎn)者或消費者栗柒，將topic連接到現(xiàn)有的應(yīng)用程序或數(shù)據(jù)系統(tǒng)礁扮。例如，一個關(guān)系數(shù)據(jù)庫的連接器可捕獲每一個變化瞬沦。

Client和Server之間的通訊，是通過一條簡單雇锡、高性能并且和開發(fā)語言無關(guān)的TCP協(xié)議逛钻。除了Java Client外，還有非常多的其它編程語言的Client锰提。

首先來了解一下Kafka所使用的基本術(shù)語：

Topic

Kafka將消息種子(Feed)分門別類曙痘，每一類的消息稱之為一個主題(Topic).

Producer

發(fā)布消息的對象稱之為主題生產(chǎn)者(Kafka topic producer)

Consumer

訂閱消息并處理發(fā)布的消息的種子的對象稱之為主題消費者(consumers)

Broker

已發(fā)布的消息保存在一組服務(wù)器中，稱之為Kafka集群立肘。集群中的每一個服務(wù)器都是一個代理(Broker). 消費者可以訂閱一個或多個主題（topic）边坤，并從Broker拉數(shù)據(jù)，從而消費這些已發(fā)布的消息谅年。

話題和日志? (Topic和Log)

讓我們更深入的了解Kafka中的Topic茧痒。

Topic是發(fā)布的消息的類別或者種子Feed名。對于每一個Topic融蹂，Kafka集群維護這一個分區(qū)的log旺订，就像下圖中的示例：

每一個分區(qū)都是一個順序的、不可變的消息隊列超燃， 并且可以持續(xù)的添加区拳。分區(qū)中的消息都被分了一個序列號，稱之為偏移量(offset)意乓，在每個分區(qū)中此偏移量都是唯一的樱调。

Kafka集群保持所有的消息，直到它們過期届良， 無論消息是否被消費了笆凌。 實際上消費者所持有的僅有的元數(shù)據(jù)就是這個偏移量，也就是消費者在這個log中的位置伙窃。 這個偏移量由消費者控制：正常情況當消費者消費消息的時候菩颖，偏移量也線性的的增加。但是實際偏移量由消費者控制为障，消費者可以將偏移量重置為更老的一個偏移量晦闰，重新讀取消息放祟。 可以看到這種設(shè)計對消費者來說操作自如， 一個消費者的操作不會影響其它消費者對此log的處理呻右。 再說說分區(qū)跪妥。Kafka中采用分區(qū)的設(shè)計有幾個目的。一是可以處理更多的消息声滥，不受單臺服務(wù)器的限制眉撵。Topic擁有多個分區(qū)意味著它可以不受限的處理更多的數(shù)據(jù)。第二落塑，分區(qū)可以作為并行處理的單元纽疟，稍后會談到這一點。

分布式(Distribution)

Log的分區(qū)被分布到集群中的多個服務(wù)器上憾赁。每個服務(wù)器處理它分到的分區(qū)污朽。 根據(jù)配置每個分區(qū)還可以復(fù)制到其它服務(wù)器作為備份容錯。 每個分區(qū)有一個leader龙考，零或多個follower蟆肆。Leader處理此分區(qū)的所有的讀寫請求，而follower被動的復(fù)制數(shù)據(jù)晦款。如果leader宕機炎功，其它的一個follower會被推舉為新的leader。 一臺服務(wù)器可能同時是一個分區(qū)的leader缓溅，另一個分區(qū)的follower蛇损。 這樣可以平衡負載，避免所有的請求都只讓一臺或者某幾臺服務(wù)器處理肛宋。

生產(chǎn)者(Producers)

生產(chǎn)者往某個Topic上發(fā)布消息州藕。生產(chǎn)者也負責選擇發(fā)布到Topic上的哪一個分區(qū)。最簡單的方式從分區(qū)列表中輪流選擇酝陈。也可以根據(jù)某種算法依照權(quán)重選擇分區(qū)床玻。開發(fā)者負責如何選擇分區(qū)的算法。

消費者(Consumers)

通常來講沉帮，消息模型可以分為兩種锈死， 隊列和發(fā)布-訂閱式。 隊列的處理方式是 一組消費者從服務(wù)器讀取消息穆壕，一條消息只有其中的一個消費者來處理待牵。在發(fā)布-訂閱模型中，消息被廣播給所有的消費者喇勋，接收到消息的消費者都可以處理此消息缨该。Kafka為這兩種模型提供了單一的消費者抽象模型： 消費者組 （consumer group）。 消費者用一個消費者組名標記自己川背。 一個發(fā)布在Topic上消息被分發(fā)給此消費者組中的一個消費者贰拿。 假如所有的消費者都在一個組中蛤袒，那么這就變成了queue模型。 假如所有的消費者都在不同的組中膨更，那么就完全變成了發(fā)布-訂閱模型妙真。 更通用的， 我們可以創(chuàng)建一些消費者組作為邏輯上的訂閱者荚守。每個組包含數(shù)目不等的消費者珍德， 一個組內(nèi)多個消費者可以用來擴展性能和容錯。正如下圖所示：

2個kafka集群托管4個分區(qū)（P0-P3）矗漾，2個消費者組锈候，消費組A有2個消費者實例，消費組B有4個缩功。

正像傳統(tǒng)的消息系統(tǒng)一樣晴及，Kafka保證消息的順序不變。 再詳細扯幾句嫡锌。傳統(tǒng)的隊列模型保持消息，并且保證它們的先后順序不變琳钉。但是势木， 盡管服務(wù)器保證了消息的順序，消息還是異步的發(fā)送給各個消費者歌懒，消費者收到消息的先后順序不能保證了啦桌。這也意味著并行消費將不能保證消息的先后順序。用過傳統(tǒng)的消息系統(tǒng)的同學肯定清楚及皂，消息的順序處理很讓人頭痛甫男。如果只讓一個消費者處理消息，又違背了并行處理的初衷验烧。 在這一點上Kafka做的更好板驳，盡管并沒有完全解決上述問題。 Kafka采用了一種分而治之的策略：分區(qū)碍拆。 因為Topic分區(qū)中消息只能由消費者組中的唯一一個消費者處理若治，所以消息肯定是按照先后順序進行處理的。但是它也僅僅是保證Topic的一個分區(qū)順序處理感混，不能保證跨分區(qū)的消息先后處理順序端幼。 所以，如果你想要順序的處理Topic的所有消息弧满，那就只提供一個分區(qū)婆跑。

Kafka的保證(Guarantees)

生產(chǎn)者發(fā)送到一個特定的Topic的分區(qū)上，消息將會按照它們發(fā)送的順序依次加入庭呜，也就是說滑进，如果一個消息M1和M2使用相同的producer發(fā)送犀忱，M1先發(fā)送，那么M1將比M2的offset低郊供，并且優(yōu)先的出現(xiàn)在日志中峡碉。

消費者收到的消息也是此順序。

如果一個Topic配置了復(fù)制因子（replication facto）為N， 那么可以允許N-1服務(wù)器宕機而不丟失任何已經(jīng)提交（committed）的消息局扶。

有關(guān)這些保證的更多詳細信息屿脐，請參見文檔的設(shè)計部分。

kafka作為一個消息系統(tǒng)

Kafka的流與傳統(tǒng)企業(yè)消息系統(tǒng)相比的概念如何地来？

傳統(tǒng)的消息有兩種模式：隊列和發(fā)布訂閱。 在隊列模式中熙掺，消費者池從服務(wù)器讀取消息（每個消息只被其中一個讀任窗摺）; 發(fā)布訂閱模式：消息廣播給所有的消費者。這兩種模式都有優(yōu)缺點币绩，隊列的優(yōu)點是允許多個消費者瓜分處理數(shù)據(jù)蜡秽，這樣可以擴展處理。但是缆镣，隊列不像多個訂閱者芽突，一旦消息者進程讀取后故障了，那么消息就丟了董瞻。而發(fā)布和訂閱允許你廣播數(shù)據(jù)到多個消費者寞蚌，由于每個訂閱者都訂閱了消息，所以沒辦法縮放處理钠糊。

kafka中消費者組有兩個概念：隊列：消費者組（consumer group）允許同名的消費者組成員瓜分處理挟秤。發(fā)布訂閱：允許你廣播消息給多個消費者組（不同名）。

kafka的每個topic都具有這兩種模式抄伍。

kafka有比傳統(tǒng)的消息系統(tǒng)更強的順序保證艘刚。

傳統(tǒng)的消息系統(tǒng)按順序保存數(shù)據(jù)，如果多個消費者從隊列消費逝慧，則服務(wù)器按存儲的順序發(fā)送消息昔脯，但是，盡管服務(wù)器按順序發(fā)送笛臣，消息異步傳遞到消費者云稚，因此消息可能亂序到達消費者。這意味著消息存在并行消費的情況沈堡，順序就無法保證静陈。消息系統(tǒng)常常通過僅設(shè)1個消費者來解決這個問題，但是這意味著沒用到并行處理。

kafka做的更好鲸拥。通過并行topic的parition —— kafka提供了順序保證和負載均衡拐格。每個partition僅由同一個消費者組中的一個消費者消費到。并確保消費者是該partition的唯一消費者刑赶，并按順序消費數(shù)據(jù)捏浊。每個topic有多個分區(qū)，則需要對多個消費者做負載均衡撞叨，但請注意金踪，相同的消費者組中不能有比分區(qū)更多的消費者，否則多出的消費者一直處于空等待牵敷，不會收到消息胡岔。

kafka作為一個存儲系統(tǒng)

所有發(fā)布消息到消息隊列和消費分離的系統(tǒng)，實際上都充當了一個存儲系統(tǒng)（發(fā)布的消息先存儲起來）枷餐。Kafka比別的系統(tǒng)的優(yōu)勢是它是一個非常高性能的存儲系統(tǒng)靶瘸。

寫入到kafka的數(shù)據(jù)將寫到磁盤并復(fù)制到集群中保證容錯性。并允許生產(chǎn)者等待消息應(yīng)答毛肋，直到消息完全寫入怨咪。

kafka的磁盤結(jié)構(gòu) - 無論你服務(wù)器上有50KB或50TB，執(zhí)行是相同的润匙。

client來控制讀取數(shù)據(jù)的位置惊暴。你還可以認為kafka是一種專用于高性能，低延遲趁桃，提交日志存儲，復(fù)制肄鸽，和傳播特殊用途的分布式文件系統(tǒng)卫病。

kafka的流處理

僅僅讀，寫和存儲是不夠的典徘，kafka的目標是實時的流處理蟀苛。

在kafka中，流處理持續(xù)獲取輸入topic的數(shù)據(jù)逮诲，進行處理加工帜平，然后寫入輸出topic。例如梅鹦，一個零售APP裆甩，接收銷售和出貨的輸入流，統(tǒng)計數(shù)量或調(diào)整價格后輸出齐唆。

可以直接使用producer和consumer API進行簡單的處理嗤栓。對于復(fù)雜的轉(zhuǎn)換，Kafka提供了更強大的Streams API≤运В可構(gòu)建聚合計算或連接流到一起的復(fù)雜應(yīng)用程序叨叙。

助于解決此類應(yīng)用面臨的硬性問題：處理無序的數(shù)據(jù)，代碼更改的再處理堪澎，執(zhí)行狀態(tài)計算等擂错。

Sterams API在Kafka中的核心：使用producer和consumer API作為輸入，利用Kafka做狀態(tài)存儲樱蛤，使用相同的組機制在stream處理器實例之間進行容錯保障钮呀。

拼在一起

消息傳遞，存儲和流處理的組合看似反常刹悴，但對于Kafka作為流式處理平臺的作用至關(guān)重要行楞。

像HDFS這樣的分布式文件系統(tǒng)允許存儲靜態(tài)文件來進行批處理。這樣系統(tǒng)可以有效地存儲和處理來自過去的歷史數(shù)據(jù)土匀。

傳統(tǒng)企業(yè)的消息系統(tǒng)允許在你訂閱之后處理未來的消息：在未來數(shù)據(jù)到達時處理它子房。

Kafka結(jié)合了這兩種能力，這種組合對于kafka作為流處理應(yīng)用和流數(shù)據(jù)管道平臺是至關(guān)重要的就轧。

批處理以及消息驅(qū)動應(yīng)用程序的流處理的概念：通過組合存儲和低延遲訂閱证杭，流處理應(yīng)用可以用相同的方式對待過去和未來的數(shù)據(jù)。它是一個單一的應(yīng)用程序妒御，它可以處理歷史的存儲數(shù)據(jù)解愤，當它處理到最后一個消息時，它進入等待未來的數(shù)據(jù)到達乎莉，而不是結(jié)束送讲。

同樣，對于流數(shù)據(jù)管道（pipeline）惋啃，訂閱實時事件的組合使得可以將Kafka用于非常低延遲的管道哼鬓；但是，可靠地存儲數(shù)據(jù)的能力使得它可以將其用于必須保證傳遞的關(guān)鍵數(shù)據(jù)边灭，或與僅定期加載數(shù)據(jù)或長時間維護的離線系統(tǒng)集成在一起异希。流處理可以在數(shù)據(jù)到達時轉(zhuǎn)換它。

有關(guān)Kafka提供的保證绒瘦，api和功能的更多信息称簿，可繼續(xù)查閱本網(wǎng)

作者：半獸人

鏈接：http://orchome.com/5

來源：OrcHome

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)惰帽，非商業(yè)轉(zhuǎn)載請注明出處憨降。