目錄：
《吃透 MQ 系列1》之核心基礎(chǔ)篇
《吃透 MQ 系列2》之扒開(kāi) Kafka 的神秘面紗
《吃透 MQ 系列3》之 Kafka 架構(gòu)設(shè)計(jì)的任督二脈
《吃透 MQ 系列4》之 Kafka 存儲(chǔ)選型的奧秘
《吃透 MQ 系列5》Kafka 精妙的高性能設(shè)計(jì)（上篇）
《吃透 MQ 系列6》Kafka 精妙的高性能設(shè)計(jì)（下篇）
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)嗎镶蹋？為什么被稱(chē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)景：記錄用戶(hù)的瀏覽踱葛、搜索丹莲、點(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ú)法滿(mǎn)足要求，然后才決定自研 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ì)類(lèi)似于 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)行分類(lèi)投遞觉渴。
此時(shí)介劫，MQ 想到了一個(gè)很聰明的辦法：它將難題直接拋給了生產(chǎn)者，要求生產(chǎn)者在發(fā)送消息時(shí)案淋，對(duì)消息進(jìn)行邏輯上的分類(lèi)座韵，因此就演進(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 最原始的消息模型条篷。這也間接解釋了第二章節(jié)中：為什么官方會(huì)將 Kakfa 同時(shí)定義成存儲(chǔ)系統(tǒng)的原因骗随。
當(dāng)然 Kafka 的精妙設(shè)計(jì)遠(yuǎn)非這些，由于篇幅原因赴叹，后面的文章再接著分析鸿染。
04 寫(xiě)在最后
這篇文章從 Kafka 的誕生背景講起，帶大家捋清了 Kafka 的定義和它要解決的問(wèn)題乞巧。另外涨椒，一步步分析了 Kafka 的消息模型和設(shè)計(jì)思想，這是 Kafka 最頂層的抽象。
