kafka的基礎(chǔ)原理和作用

這篇文章主要講解了“kafka的基礎(chǔ)原理和作用”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“kafka的基礎(chǔ)原理和作用”吧！

Kafka作為一個(gè)分布式的流平臺(tái)，這到底意味著什么？

我們認(rèn)為，一個(gè)流處理平臺(tái)具有三個(gè)關(guān)鍵能力：

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

2. 以容錯(cuò)的方式存儲(chǔ)消息（流）。

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

什么是kakfa的優(yōu)勢？它主要應(yīng)用于2大類應(yīng)用：

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

2. 構(gòu)建實(shí)時(shí)流的應(yīng)用程序，對(duì)數(shù)據(jù)流進(jìn)行轉(zhuǎn)換或反應(yīng)。

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

首先幾個(gè)概念：

1. kafka作為一個(gè)集群運(yùn)行在一個(gè)或多個(gè)服務(wù)器上。

2. kafka集群存儲(chǔ)的消息是以topic為類別記錄的。

3. 每個(gè)消息（也叫記錄record，我習(xí)慣叫消息）是由一個(gè)key，一個(gè)value和時(shí)間戳構(gòu)成。

kafka有四個(gè)核心API：

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

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

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

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

Client和Server之間的通訊，是通過一條簡單、高性能并且和開發(fā)語言無關(guān)的TCP協(xié)議。并且該協(xié)議保持與老版本的兼容。Kafka提供了Java Client（客戶端）。除了Java Client外，還有非常多的其它編程語言的Client。

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

Topic

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

Producer

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

Consumer

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

Broker

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

主題和日志 (Topic和Log)

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

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

每一個(gè)分區(qū)都是一個(gè)順序的、不可變的消息隊(duì)列， 并且可以持續(xù)的添加。分區(qū)中的消息都被分了一個(gè)序列號(hào)，稱之為偏移量(offset)，在每個(gè)分區(qū)中此偏移量都是唯一的。

Kafka集群保持所有的消息，直到它們過期， 無論消息是否被消費(fèi)了。 實(shí)際上消費(fèi)者所持有的僅有的元數(shù)據(jù)就是這個(gè)偏移量，也就是消費(fèi)者在這個(gè)log中的位置。 這個(gè)偏移量由消費(fèi)者控制：正常情況當(dāng)消費(fèi)者消費(fèi)消息的時(shí)候，偏移量也線性的的增加。但是實(shí)際偏移量由消費(fèi)者控制，消費(fèi)者可以將偏移量重置為更老的一個(gè)偏移量，重新讀取消息。 可以看到這種設(shè)計(jì)對(duì)消費(fèi)者來說操作自如， 一個(gè)消費(fèi)者的操作不會(huì)影響其它消費(fèi)者對(duì)此log的處理。 再說說分區(qū)。Kafka中采用分區(qū)的設(shè)計(jì)有幾個(gè)目的。一是可以處理更多的消息，不受單臺(tái)服務(wù)器的限制。Topic擁有多個(gè)分區(qū)意味著它可以不受限的處理更多的數(shù)據(jù)。第二，分區(qū)可以作為并行處理的單元，稍后會(huì)談到這一點(diǎn)。

分布式(Distribution)

Log的分區(qū)被分布到集群中的多個(gè)服務(wù)器上。每個(gè)服務(wù)器處理它分到的分區(qū)。 根據(jù)配置每個(gè)分區(qū)還可以復(fù)制到其它服務(wù)器作為備份容錯(cuò)。 每個(gè)分區(qū)有一個(gè)leader，零或多個(gè)follower。Leader處理此分區(qū)的所有的讀寫請(qǐng)求，而follower被動(dòng)的復(fù)制數(shù)據(jù)。如果leader宕機(jī)，其它的一個(gè)follower會(huì)被推舉為新的leader。 一臺(tái)服務(wù)器可能同時(shí)是一個(gè)分區(qū)的leader，另一個(gè)分區(qū)的follower。 這樣可以平衡負(fù)載，避免所有的請(qǐng)求都只讓一臺(tái)或者某幾臺(tái)服務(wù)器處理。

Geo-Replication(異地?cái)?shù)據(jù)同步技術(shù))

Kafka MirrorMaker為群集提供geo-replication支持。借助MirrorMaker，消息可以跨多個(gè)數(shù)據(jù)中心或云區(qū)域進(jìn)行復(fù)制。 您可以在active/passive場景中用于備份和恢復(fù); 或者在active/passive方案中將數(shù)據(jù)置于更接近用戶的位置，或數(shù)據(jù)本地化。

生產(chǎn)者(Producers)

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

消費(fèi)者(Consumers)

通常來講，消息模型可以分為兩種， 隊(duì)列和發(fā)布-訂閱式。 隊(duì)列的處理方式是 一組消費(fèi)者從服務(wù)器讀取消息，一條消息只有其中的一個(gè)消費(fèi)者來處理。在發(fā)布-訂閱模型中，消息被廣播給所有的消費(fèi)者，接收到消息的消費(fèi)者都可以處理此消息。Kafka為這兩種模型提供了單一的消費(fèi)者抽象模型： 消費(fèi)者組 （consumer group）。 消費(fèi)者用一個(gè)消費(fèi)者組名標(biāo)記自己。 一個(gè)發(fā)布在Topic上消息被分發(fā)給此消費(fèi)者組中的一個(gè)消費(fèi)者。 假如所有的消費(fèi)者都在一個(gè)組中，那么這就變成了queue模型。 假如所有的消費(fèi)者都在不同的組中，那么就完全變成了發(fā)布-訂閱模型。 更通用的， 我們可以創(chuàng)建一些消費(fèi)者組作為邏輯上的訂閱者。每個(gè)組包含數(shù)目不等的消費(fèi)者， 一個(gè)組內(nèi)多個(gè)消費(fèi)者可以用來擴(kuò)展性能和容錯(cuò)。正如下圖所示：
2個(gè)kafka集群托管4個(gè)分區(qū)（P0-P3），2個(gè)消費(fèi)者組，消費(fèi)組A有2個(gè)消費(fèi)者實(shí)例，消費(fèi)組B有4個(gè)。

正像傳統(tǒng)的消息系統(tǒng)一樣，Kafka保證消息的順序不變。 再詳細(xì)扯幾句。傳統(tǒng)的隊(duì)列模型保持消息，并且保證它們的先后順序不變。但是， 盡管服務(wù)器保證了消息的順序，消息還是異步的發(fā)送給各個(gè)消費(fèi)者，消費(fèi)者收到消息的先后順序不能保證了。這也意味著并行消費(fèi)將不能保證消息的先后順序。用過傳統(tǒng)的消息系統(tǒng)的同學(xué)肯定清楚，消息的順序處理很讓人頭痛。如果只讓一個(gè)消費(fèi)者處理消息，又違背了并行處理的初衷。 在這一點(diǎn)上Kafka做的更好，盡管并沒有完全解決上述問題。 Kafka采用了一種分而治之的策略：分區(qū)。 因?yàn)門opic分區(qū)中消息只能由消費(fèi)者組中的唯一一個(gè)消費(fèi)者處理，所以消息肯定是按照先后順序進(jìn)行處理的。但是它也僅僅是保證Topic的一個(gè)分區(qū)順序處理，不能保證跨分區(qū)的消息先后處理順序。 所以，如果你想要順序的處理Topic的所有消息，那就只提供一個(gè)分區(qū)。

Kafka的保證(Guarantees)

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

• 消費(fèi)者收到的消息也是此順序。

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

有關(guān)這些保證的更多詳細(xì)信息，請(qǐng)參見文檔的設(shè)計(jì)部分。

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

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

傳統(tǒng)的消息有兩種模式：隊(duì)列和發(fā)布訂閱。 在隊(duì)列模式中，消費(fèi)者池從服務(wù)器讀取消息（每個(gè)消息只被其中一個(gè)讀?。? 發(fā)布訂閱模式：消息廣播給所有的消費(fèi)者。這兩種模式都有優(yōu)缺點(diǎn)，隊(duì)列的優(yōu)點(diǎn)是允許多個(gè)消費(fèi)者瓜分處理數(shù)據(jù)，這樣可以擴(kuò)展處理。但是，隊(duì)列不像多個(gè)訂閱者，一旦消息者進(jìn)程讀取后故障了，那么消息就丟了。而發(fā)布和訂閱允許你廣播數(shù)據(jù)到多個(gè)消費(fèi)者，由于每個(gè)訂閱者都訂閱了消息，所以沒辦法縮放處理。

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

kafka的每個(gè)topic都具有這兩種模式。

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

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

kafka做的更好。通過并行topic的parition —— kafka提供了順序保證和負(fù)載均衡。每個(gè)partition僅由同一個(gè)消費(fèi)者組中的一個(gè)消費(fèi)者消費(fèi)到。并確保消費(fèi)者是該partition的唯一消費(fèi)者，并按順序消費(fèi)數(shù)據(jù)。每個(gè)topic有多個(gè)分區(qū)，則需要對(duì)多個(gè)消費(fèi)者做負(fù)載均衡，但請(qǐng)注意，相同的消費(fèi)者組中不能有比分區(qū)更多的消費(fèi)者，否則多出的消費(fèi)者一直處于空等待，不會(huì)收到消息。

kafka作為一個(gè)存儲(chǔ)系統(tǒng)

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

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

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

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

kafka的流處理

僅僅讀，寫和存儲(chǔ)是不夠的，kafka的目標(biāo)是實(shí)時(shí)的流處理。

在kafka中，流處理持續(xù)獲取輸入topic的數(shù)據(jù)，進(jìn)行處理加工，然后寫入輸出topic。例如，一個(gè)零售APP，接收銷售和出貨的輸入流，統(tǒng)計(jì)數(shù)量或調(diào)整價(jià)格后輸出。

可以直接使用producer和consumer API進(jìn)行簡單的處理。對(duì)于復(fù)雜的轉(zhuǎn)換，Kafka提供了更強(qiáng)大的Streams API?？蓸?gòu)建聚合計(jì)算或連接流到一起的復(fù)雜應(yīng)用程序。

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

Sterams API在Kafka中的核心：使用producer和consumer API作為輸入，利用Kafka做狀態(tài)存儲(chǔ)，使用相同的組機(jī)制在stream處理器實(shí)例之間進(jìn)行容錯(cuò)保障。

拼在一起

消息傳遞，存儲(chǔ)和流處理的組合看似反常，但對(duì)于Kafka作為流式處理平臺(tái)的作用至關(guān)重要。

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

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

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

批處理以及消息驅(qū)動(dòng)應(yīng)用程序的流處理的概念：通過組合存儲(chǔ)和低延遲訂閱，流處理應(yīng)用可以用相同的方式對(duì)待過去和未來的數(shù)據(jù)。它是一個(gè)單一的應(yīng)用程序，它可以處理歷史的存儲(chǔ)數(shù)據(jù)，當(dāng)它處理到最后一個(gè)消息時(shí)，它進(jìn)入等待未來的數(shù)據(jù)到達(dá)，而不是結(jié)束。

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

感謝各位的閱讀，以上就是“kafka的基礎(chǔ)原理和作用”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)kafka的基礎(chǔ)原理和作用這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！