扒開 Kafka 的神秘面紗

 01 為什么從 Kafka 開始？  

之所以選擇從 Kafka 開始，有 3 點(diǎn)考慮：

第一，RocketMQ 和 Kafka 是目前最熱門的兩種消息中間件，互聯(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 扒開 Kafka 的面紗  

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

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

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

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

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

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

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

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

Kafka 最開始其實(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。

所以從一開始，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 版本開始，就已經(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、搜索引擎中。

可見 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 最畫龍點(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 最原始的消息模型。

這也間接解釋了第二章節(jié)中：為什么官方會(huì)將 Kakfa 同時(shí)定義成存儲(chǔ)系統(tǒng)的原因。

當(dāng)然 Kafka 的精妙設(shè)計(jì)遠(yuǎn)非這些，由于篇幅原因，后面的文章再接著分析。

 04 寫在最后  

這篇文章從 Kafka 的誕生背景講起，帶大家捋清了 Kafka 的定義和它要解決的問(wèn)題。

另外，一步步分析了 Kafka 的消息模型和設(shè)計(jì)思想，這是 Kafka 最頂層的抽象。