什么是Kafka最原始的消息模型

本篇內(nèi)容介紹了“什么是Kafka最原始的消息模型”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

01 為什么從 Kafka 開(kāi)始?

《吃透 MQ 》的開(kāi)篇 圍繞 MQ 「一發(fā)一存一消費(fèi)」的本質(zhì)展開(kāi)，講解了 MQ 的通用知識(shí)，同時(shí)系統(tǒng)性地回答了：如何著手設(shè)計(jì)一個(gè) MQ?

從這篇文章開(kāi)始，我會(huì)講解具體的消息中間件，之所以選擇從 Kafka 開(kāi)始，有 3 點(diǎn)考慮：

第一，RocketMQ 和 Kafka 是目前最熱門(mén)的兩種消息中間件，互聯(lián)網(wǎng)公司應(yīng)用最為廣泛，將作為本系列的重點(diǎn)。

第二，從 MQ 的發(fā)展歷程來(lái)看，Kafka 先于 RocketMQ 誕生，并且阿里團(tuán)隊(duì)在實(shí)現(xiàn) RocketMQ 時(shí)，充分借鑒了 Kafka  的設(shè)計(jì)思想。掌握了 Kafka 的設(shè)計(jì)原理，后面再去理解 RocketMQ 會(huì)容易很多。

第三，Kafka 其實(shí)是一個(gè)輕量級(jí)的 MQ，它具備 MQ 最基礎(chǔ)的能力，但是在延遲隊(duì)列、重試機(jī)制等高級(jí)特性上并未做支持，因此降低了實(shí)現(xiàn)復(fù)雜度。從  Kafka 入手，有利于大家快速掌握 MQ 最核心的東西。

交代完背景，下面請(qǐng)大家跟著我的思路，一起由淺入深地分析下 Kafka。

02 扒開(kāi) Kafka 的面紗

在深入分析一門(mén)技術(shù)之前，不建議上來(lái)就去了解架構(gòu)以及技術(shù)細(xì)節(jié)，而是先弄清楚它是什么?它是為了解決什么問(wèn)題而產(chǎn)生的?

掌握這些背景知識(shí)后，有利于我們理解它背后的設(shè)計(jì)考慮以及設(shè)計(jì)思想。

在寫(xiě)這篇文章時(shí)，我查閱了很多資料，關(guān)于 Kafka 的定義可以說(shuō)五花八門(mén)，不仔細(xì)推敲很容易懵圈，我覺(jué)得有必要帶大家捋一捋。

我們先看看 Kafka 官網(wǎng)給自己下的定義：

• Apache Kafka is an open-source distributed event streaming platform.

翻譯成中文就是：Apache Kafka 是一個(gè)開(kāi)源的分布式流處理平臺(tái)。

Kafka 不是一個(gè)消息系統(tǒng)嗎?為什么被稱為分布式的流處理平臺(tái)呢?這兩者是一回事嗎?

一定有讀者會(huì)有這樣的疑問(wèn)，要解釋這個(gè)問(wèn)題，需要先從 Kafka 的誕生背景說(shuō)起。

Kafka 最開(kāi)始其實(shí)是 Linkedin 內(nèi)部孵化的項(xiàng)目，在設(shè)計(jì)之初是被當(dāng)做「數(shù)據(jù)管道」，用于處理以下兩種場(chǎng)景：

• 1、運(yùn)營(yíng)活動(dòng)場(chǎng)景：記錄用戶的瀏覽、搜索、點(diǎn)擊、活躍度等行為。

• 2、系統(tǒng)運(yùn)維場(chǎng)景：監(jiān)控服務(wù)器的 CPU、內(nèi)存、請(qǐng)求耗時(shí)等性能指標(biāo)。

可以看到這兩種數(shù)據(jù)都屬于日志范疇，特點(diǎn)是：數(shù)據(jù)實(shí)時(shí)生產(chǎn)，而且數(shù)據(jù)量很大。

Linkedin 最初也嘗試過(guò)用 ActiveMQ 來(lái)解決數(shù)據(jù)傳輸問(wèn)題，但是性能無(wú)法滿足要求，然后才決定自研 Kafka。

所以從一開(kāi)始，Kafka 就是為實(shí)時(shí)日志流而生的。了解了這個(gè)背景，就不難理解 Kafka 與流數(shù)據(jù)的關(guān)系了，以及 Kafka  為什么在大數(shù)據(jù)領(lǐng)域有如此廣泛的應(yīng)用?也是因?yàn)樗畛蹙褪菫榻鉀Q大數(shù)據(jù)的管道問(wèn)題而誕生的。

接著再解釋下：為什么 Kafka 被官方定義成流處理平臺(tái)呢?它不就提供了一個(gè)數(shù)據(jù)通道能力嗎，怎么還和平臺(tái)扯上關(guān)系了?

這是因?yàn)?Kafka 從 0.8 版本開(kāi)始，就已經(jīng)在提供一些和數(shù)據(jù)處理有關(guān)的組件了，比如：

• 1、Kafka Streams：一個(gè)輕量化的流計(jì)算庫(kù)，性質(zhì)類似于 Spark、Flink。

• 2、Kafka Connect：一個(gè)數(shù)據(jù)同步工具，能將 Kafka 中的數(shù)據(jù)導(dǎo)入到關(guān)系數(shù)據(jù)庫(kù)、Hadoop、搜索引擎中。

可見(jiàn) Kafka 的野心不僅僅是一個(gè)消息系統(tǒng)，它早就在往「實(shí)時(shí)流處理平臺(tái)」方向發(fā)展了。

這時(shí)候，再回來(lái)看 Kafka 的官網(wǎng)介紹提到的 3 種能力，也不難理解了：

• 1、數(shù)據(jù)的發(fā)布和訂閱能力(消息隊(duì)列)

• 2、數(shù)據(jù)的分布式存儲(chǔ)能力(存儲(chǔ)系統(tǒng))

• 3、數(shù)據(jù)的實(shí)時(shí)處理能力(流處理引擎)

這樣，kafka 的發(fā)展歷史和定義基本縷清了。當(dāng)然，這個(gè)系列僅僅關(guān)注 Kafka 的前兩種能力，因?yàn)檫@兩種能力都和 MQ 強(qiáng)相關(guān)。

03 從 Kafka的消息模型說(shuō)起

理解了 Kafka 的定位以及它的誕生背景，接著我們分析下 Kafka 的設(shè)計(jì)思想。

上篇文章中我提到過(guò)：要吃透一個(gè)MQ，建議從「消息模型」這種最核心的理論層面入手，而不是一上來(lái)就去看技術(shù)架構(gòu)，更不要直接進(jìn)入技術(shù)細(xì)節(jié)。

所謂消息模型，可以理解成一種邏輯結(jié)構(gòu)，它是技術(shù)架構(gòu)再往上的一層抽象，往往隱含了最核心的設(shè)計(jì)思想。

下面我們嘗試分析下 Kafka 的消息模型，看看它究竟是如何演化來(lái)的?

首先，為了將一份消息數(shù)據(jù)分發(fā)給多個(gè)消費(fèi)者，并且每個(gè)消費(fèi)者都能收到全量的消息，很自然的想到了廣播。

緊接著問(wèn)題出現(xiàn)了：來(lái)一條消息，就廣播給所有消費(fèi)者，但并非每個(gè)消費(fèi)者都想要全部的消息，比如消費(fèi)者 A 只想要消息1、2、3，消費(fèi)者 B  只想要消息4、5、6，這時(shí)候該怎么辦呢?

這個(gè)問(wèn)題的關(guān)鍵點(diǎn)在于：MQ 不理解消息的語(yǔ)義，它根本無(wú)法做到對(duì)消息進(jìn)行分類投遞。

此時(shí)，MQ 想到了一個(gè)很聰明的辦法：它將難題直接拋給了生產(chǎn)者，要求生產(chǎn)者在發(fā)送消息時(shí)，對(duì)消息進(jìn)行邏輯上的分類，因此就演進(jìn)出了我們熟知的 Topic  以及發(fā)布-訂閱模型。

這樣，消費(fèi)者只需要訂閱自己感興趣的 Topic，然后從 Topic 中獲取消息即可。

但是這樣做了之后，仍然存在一個(gè)問(wèn)題：假如多個(gè)消費(fèi)者都對(duì)同一個(gè) Topic 感興趣(如下圖中的消費(fèi)者 C)，那又該如何解決呢?

如果采用傳統(tǒng)的隊(duì)列模式(單播)，那當(dāng)一個(gè)消費(fèi)者從隊(duì)列中取走消息后，這條消息就會(huì)被刪除，另外一個(gè)消費(fèi)者就拿不到了。

這個(gè)時(shí)候，很自然又想到下面的解決方案：

也就是：當(dāng) Topic 每增加一個(gè)新的消費(fèi)者，就「復(fù)制」一個(gè)完全一樣的數(shù)據(jù)隊(duì)列。

這樣問(wèn)題是解決了，但是隨著下游消費(fèi)者數(shù)量變多，將引發(fā) MQ 性能的快速退化。尤其對(duì)于 Kafka  來(lái)說(shuō)，它在誕生之初就是處理大數(shù)據(jù)場(chǎng)景的，這種復(fù)制操作顯然成本太高了。

這時(shí)候，就有了 Kafka 最畫(huà)龍點(diǎn)睛的一個(gè)解法：它將所有消息進(jìn)行了持久化存儲(chǔ)，由消費(fèi)者自己各取所需，想取哪個(gè)消息，想什么時(shí)候取都行，只需要傳遞一個(gè)消息的  offset 即可。

這樣一個(gè)根本性改變，徹底將復(fù)雜的消費(fèi)問(wèn)題又轉(zhuǎn)嫁給消費(fèi)者了，這樣使得 Kafka 本身的復(fù)雜度大大降低，從而為它的高性能和高擴(kuò)展打下了良好的基礎(chǔ)。(這是  Kafka 不同于 ActiveMQ 和 RabbitMQ 最核心的地方)

最后，簡(jiǎn)化一下，就是下面這張圖：

“什么是Kafka最原始的消息模型”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！