Kafka只是消息引擎系統嗎？Apache Kafka 的前生今世

Kafka只是消息引擎系統嗎？Apache Kafka 的前生今世

物聯網雲平臺開發武器庫 https://www.yuque.com/shizhiy...

要搞清楚這個問題，咱們不可避免地要了解一下 Apache Kafka 的發展歷程。有的時候咱們會以爲說了解一個系統或框架的前世此生彷佛沒什麼必要，直接開始學具體的技術不是更快更好嗎？

其實，不管是學習哪一種技術，直接扎到具體的細節中，亦或是從一個很小的點開始學習，你很快就會感到厭煩。爲何呢？由於你雖然快速地搞定了某個技術細節，但沒法創建全局的認知觀，這會致使你只是在單個的點上有所進展，卻無法將其串聯成一條線進而擴展成一個面，從而實現系統地學習。

我這麼說是有依據的，由於這就是我當初學習 Kafka 的方式。你可能不會相信，我閱讀Kafka 源碼就是從 utils 包開始的。顯然，咱們不用看源碼也知道這玩意是幹什麼用的，對吧？就是個工具類包嘛，並且這種閱讀源碼的方式是極其低效的。就像我說的，我是在一個點一個點地學習，但所有學完以後壓根沒有任何感受，依然不瞭解 Kafka，由於不知道這些包中的代碼組合在一塊兒能達成什麼效果。因此我說它是很低效的學習方法。後來我修改了學習的方法，轉而從自上而下的角度去理解 Kafka，居然發現了不少以前學習過程當中忽略掉的東西。更特別地是，我發現這種學習方法可以幫助我維持較長時間的學習興趣，不會階段性地產生厭煩情緒。特別是在瞭解 Apache Kafka 整個發展歷史的過程當中我愉快地學到了不少運營大型開源軟件社區的知識和經驗，可謂是技術以外的一大收穫.

縱觀 Kafka 的發展脈絡，它的確是從消息引擎起家的，但正如文章標題所問，Apache Kafka 真的只是消息引擎嗎？

一般，在回答這個問題以前不少文章可能就要這樣展開了：
那咱們先來討論下什麼是消息引擎以及消息引擎能作什麼事情。算了，我仍是直給吧，就不從「唐堯虞舜」提及了。

這個問題的答案是，Apache Kafka 是消息引擎系統，也是一個分佈式流處理平臺（Distributed Streaming Platform）。若是你通讀全篇文字但只能記住一句話，我但願你記住的就是這句。再強調一遍，Kafka 是消息引擎系統，也是分佈式流處理平臺。
**
衆所周知，Kafka 是 LinkedIn 公司內部孵化的項目。根據我和 Kafka 創始團隊成員的交流以及查閱到的公開信息顯示，LinkedIn 最開始有強烈的數據強實時處理方面的需求，其內部的諸多子系統要執行多種類型的數據處理與分析，主要包括業務系統和應用程序性能監控，以及用戶行爲數據處理等。

當時他們碰到的主要問題包括：

• 數據正確性不足。由於數據的收集主要採用輪詢（Polling）的方式，如何肯定輪詢的間隔時間就變成了一個高度經驗化的事情。雖然能夠採用一些相似於啓發式算法（Heuristic）來幫助評估間隔時間值，但一旦指定不當，必然會形成較大的數據誤差。
• 系統高度定製化，維護成本高。各個業務子系統都須要對接數據收集模塊，引入了大量的定製開銷和人工成本。

爲了解決這些問題，LinkedIn 工程師嘗試過使用 ActiveMQ 來解決這些問題，但效果並不理想。顯然須要有一個「大一統」的系統來取代現有的工做方式，而這個系統就是 Kafka。Kafka 自誕生伊始是以消息引擎系統的面目出如今大衆視野中的。若是翻看 0.10.0.0 以前的官網說明，你會發現 Kafka 社區將其清晰地定位爲一個分佈式、分區化且帶備份功能的提交日誌（Commit Log）服務。

這裏引出一個題外話，你可能好奇 Kafka 這個名字的由來，實際上 Kafka 做者之一 JayKreps 曾經談及過命名的緣由。

由於 Kafka 系統的寫性能很強，因此找了個做家的名字來命名彷佛是一個好主意。大學期間我上了不少文學課，很是喜歡 Franz Kafka 這個做家，另外爲開源軟件起這個名字聽上去很酷。

言歸正傳，Kafka 在設計之初就旨在提供三個方面的特性：

1. 提供一套 API 實現生產者和消費者；
2. 下降網絡傳輸和磁盤存儲開銷；
3. 實現高伸縮性架構。

咱們將陸續探討 Kafka 是如何作到以上三點的。總之隨着 Kafka 的不斷完善，Jay 等大神們終於意識到將其開源惠及更多的人是一個很是棒的主意，所以在2011 年 Kafka 正式進入到 Apache 基金會孵化並於次年 10 月順利畢業成爲 Apache 頂級項目。

開源以後的 Kafka 被愈來愈多的公司應用到它們企業內部的數據管道中，特別是在大數據工程領域，Kafka 在承接上下游、串聯數據流管道方面發揮了重要的做用：全部的數據幾乎都要從一個系統流入 Kafka 而後再流向下游的另外一個系統中。這樣的使用方式家常便飯以致於引起了 Kafka 社區的思考：

與其我把數據從一個系統傳遞到下一個系統中作處理，我爲什麼不本身實現一套流處理框架呢？**

基於這個考量，Kafka 社區於 0.10.0.0 版本正式推出了流處理組件 Kafka Streams，也正是從這個版本開始，Kafka 正式「變身」爲分佈式的流處理平臺，而不只僅是消息引擎系統了。今天 Apache Kafka 是和 Apache Storm、
Apache Spark 和 Apache Flink 同等級的實時流處理平臺。

誠然，目前國內對 Kafka 是流處理平臺的認知還尚不普及，其核心的流處理組件 Kafka Streams 更是少有大廠在使用。但咱們也欣喜地看到，隨着在 Kafka 峯會上各路大神們的鼎力宣傳，現在利用 Kafka 構建流處理平臺的案例層出不窮，而瞭解並有意願使用 Kafka Streams 的廠商也是愈來愈多，所以我我的對於 Kafka 流處理平臺的前景也是很是樂觀的。

你可能會有這樣的疑問：做爲流處理平臺，Kafka 與其餘主流大數據流式計算框架相比，優點在哪裏呢？我能想到的有兩點。

第一點是更容易實現端到端的正確性（Correctness）。Google 大神 Tyler 曾經說過，流處理要最終替代它的「兄弟」批處理須要具有兩點核心優點：要實現正確性和提供可以推導時間的工具。實現正確性是流處理可以匹敵批處理的基石。正確性一直是批處理的強項，而實現正確性的基石則是要求框架能提供精確一次處理語義，即處理一條消息有且只有一次機會可以影響系統狀態。目前主流的大數據流處理框架都宣稱實現了精確一次處理語義，但這是有限定條件的，即它們只能實現框架內的精確一次處理語義，沒法實現端到端的。這是爲何呢？由於當這些框架與外部消息引擎系統結合使用時，它們沒法影響到外部系統的處理語義，因此若是你搭建了一套環境使得 Spark 或 Flink 從 Kafka 讀取消息以後進行有狀態的數據計算，最後再寫回 Kafka，那麼你只能保證在 Spark 或 Flink 內部，這條消
息對於狀態的影響只有一次。可是計算結果有可能屢次寫入到 Kafka，由於它們不能控制 Kafka 的語義處理。相反地，Kafka 則不是這樣，由於全部的數據流轉和計算都在 Kafka 內部完成，故 Kafka 能夠實現端到端的精確一次處理語義。

可能助力 Kafka 勝出的第二點是它本身對於流式計算的定位。官網上明確標識 Kafka Streams 是一個用於搭建實時流處理的客戶端庫而非是一個完整的功能系統。這就是說，你不能指望着 Kafka 提供相似於集羣調度、彈性部署等開箱即用的運維特性，你須要本身選擇適合的工具或系統來幫助 Kafka 流處理應用實現這些功能。讀到這你可能會說這怎麼算是優勢呢？坦率來講，這的確是一個「雙刃劍」的設計，也是Kafka 社區「劍走偏鋒」不正面 PK 其餘流計算框架的特地考量。大型公司的流處理平臺必定是大規模部署的，所以具有集羣調度功能以及靈活的部署方案是不可或缺的要素。但畢竟這世界上還存在着不少中小企業，它們的流處理數據量並不巨大，邏輯也並不複雜，部署幾臺或十幾臺機器足以應付。在這樣的需求之下，搭建重量級的完整性平臺實在是「殺雞焉用牛刀」，而這正是 Kafka 流處理組件的用武之地。所以從這個角度來講，將來在流處理框架中，Kafka 應該是有一席之地的。除了消息引擎和流處理平臺，Kafka 還有別的用途嗎？固然有！你能想象嗎，Kafka 可以被用做分佈式存儲系統。Kafka 做者之一 Jay Kreps 曾經專門寫過一篇文章闡述爲何能把 Kafka 用做分佈式存儲。不過我以爲你姑且瞭解下就行了，我從沒有見過在實際生產環境中，有人把 Kafka 看成持久化存儲來用 。

說了這麼多，我只想闡述這樣的一個觀點：Apache Kafka 從一個優秀的消息引擎系統起家，逐漸演變成如今分佈式的流處理平臺。你不只要熟練掌握它做爲消息引擎系統的非凡特性及使用技巧，最好還要多瞭解下其流處理組件的設計與案例應用。