Kafka的版本號(極度重要！！！)

Kafka的版本號(極度重要！！！)

版本號實在是過重要了，我以爲它甚至是你往後可否用好 Kafka 的關鍵。

上一期我介紹了目前流行的幾種 Kafka 發行版，其實不管是哪一種 Kafka，本質上都內嵌了最核心的 Apache Kafka，也就是社區版 Kafka，那今天咱們就來講說 Apache Kafka 版本號的問題。在開始以前，我想強調一下後面出現的全部「版本」這個詞均表示 Kafka 具體的版本號，而非上一篇中的 Kafka 種類，這一點切記切記！

那麼如今你可能會有這樣的疑問：我爲何須要關心版本號的問題呢？直接使用最新版本不就行了嗎？固然了，這的確是一種有效的選擇版本的策略，但我想強調的是這種策略並不是在任何場景下都適用。若是你不瞭解各個版本之間的差別和功能變化，你怎麼可以準確地評判某 Kafka 版本是否是知足你的業務需求呢？所以在深刻學習 Kafka 以前，花些時間搞明白版本演進，其實是很是划算的一件事。

Kafka 版本命名

當前 Apache Kafka 已經迭代到 2.2 版本，社區正在爲 2.3.0 發版日期進行投票，相信2.3.0 也會立刻發佈。可是稍微有些使人吃驚的是，不少人對於 Kafka 的版本命名理解存在歧義。好比咱們在官網上下載 Kafka 時，會看到這樣的版本：

因而有些同窗就會納悶，難道 Kafka 版本號不是 2.11 或 2.12 嗎？其實否則，前面的版本號是編譯 Kafka 源代碼的 Scala 編譯器版本。Kafka 服務器端的代碼徹底由 Scala 語言編寫，Scala 同時支持面向對象編程和函數式編程，用 Scala 寫成的源代碼編譯以後也是普通的「.class」文件，所以咱們說 Scala 是 JVM 系的語言，它的不少設計思想都是爲人稱道的。

事實上目前 Java 新推出的不少功能都是在不斷向 Scala 語言靠近罷了，好比 Lambda 表達式、函數式接口、val 變量等。一個有意思的事情是，Kafka 新版客戶端代碼徹底由 Java語言編寫，因而有些人展開了「Java VS Scala」的大討論，並從語言特性的角度嘗試分析Kafka 社區爲何放棄 Scala 轉而使用 Java 重寫客戶端代碼。其實事情遠沒有那麼複雜，僅僅是由於社區來了一批 Java 程序員而已，而之前老的 Scala 程序員隱退罷了。可能有點跑題了，但無論怎樣我依然建議你有空去學學 Scala 語言。

回到剛纔的版本號討論。如今你應該知道了對於 kafka-2.11-2.1.1 的提法，真正的 Kafka版本號其實是 2.1.1。那麼這個 2.1.1 又表示什麼呢？

前面的 2 表示大版本號，即 Major Version；
中間的 1 表示小版本號或次版本號，即 Minor Version；
最後的 1 表示修訂版本號，也就是 Patch 號。

Kafka 社區在發佈 1.0.0 版本後特地寫過一篇文章，宣佈 Kafka版本命名規則正式從 4 位演進到 3 位，好比 0.11.0.0 版本就是 4 位版本號

在我看來像 0.11.0.0 這樣的版本雖然有 4 位版本號，但其實它的大版本是 0.11，而不是 0，因此若是這樣來看的話 Kafka 版本號歷來都是由 3 個部分構成，即「大版本號 - 小版本號 - Patch 號」。這種視角能夠統一全部的Kafka 版本命名，也方便咱們往後的討論。咱們來複習一下，假設碰到的 Kafka 版本是0.10.2.2，你如今就知道了它的大版本是 0.10，小版本是 2，總共打了兩個大的補丁，Patch 號是 2。

Kafka 版本演進

Kafka 目前總共演進了 7 個大版本，分別是 0.七、0.八、0.九、0.十、0.十一、1.0 和 2.0，其中的小版本和 Patch 版本不少。哪些版本引入了哪些重大的功能改進？關於這個問題，我建議你最好能作到如數家珍，由於這樣不只令你在和別人交談 Kafka 時顯得很酷，並且若是你要向架構師轉型或者已然是架構師，那麼這些都是可以幫助你進行技術選型、架構評估的重要依據。

咱們先從 0.7 版本提及，實際上也沒什麼可說的，這是最先開源時的「上古」版本了。這個版本只提供了最基礎的消息隊列功能，甚至連副本機制都沒有，我實在想不出有什麼理由你要使用這個版本，所以一旦有人向你推薦這個版本，果斷走開就行了。

Kafka 從 0.7 時代演進到 0.8 以後正式引入了副本機制，至此 Kafka 成爲了一個真正意義上完備的分佈式高可靠消息隊列解決方案。有了副本備份機制，Kafka 就可以比較好地作到消息無丟失。那時候生產和消費消息使用的仍是老版本的客戶端 API，所謂的老版本是指當你用它們的 API 開發生產者和消費者應用時，你須要指定 ZooKeeper 的地址而非 Broker的地址。

若是你如今尚不能理解這二者的區別也不要緊。老版本客戶端有不少的問題，特別是生產者 API，它默認使用同步方式發送消息，能夠想見其吞吐量必定不會過高。雖然它也支持異步的方式，但實際場景中可能會形成消息的丟失，因
此 0.8.2.0 版本社區引入了新版本 Producer API，即須要指定 Broker 地址的 Producer。據我所知，國內依然有少部分用戶在使用 0.8.1.一、0.8.2 版本。個人建議是儘可能使用比較新的版本。若是你不能升級大版本，我也建議你至少要升級到 0.8.2.2 這個版本，由於該版本中老版本消費者 API 是比較穩定的。


時間來到了 2015 年 11 月，社區正式發佈了 0.9.0.0 版本。在我看來這是一個重量級的大版本更迭，0.9 大版本增長了基礎的安全認證 / 權限功能，同時使用 Java 重寫了新版本消費者 API，另外還引入了 Kafka Connect 組件用於實現高性能的數據抽取。若是這麼多眼花繚亂的功能你一時無暇顧及，那麼我但願你記住這個版本的另外一個好處，那就是新版本Producer API 在這個版本中算比較穩定了。若是你使用 0.9 做爲線上環境不妨切換到新版本 Producer，這是此版本一個不太爲人所知的優點。但和 0.8.2 引入新 API 問題相似，不要使用新版本 ConsumerAPI，由於 Bug 超多的，絕對用到你崩潰。

即便你反饋問題到社區，社區也不會管的，它會無腦地推薦你升級到新版本再試試，所以千萬別用 0.9 的新版本 Consumer API。對於國內一些使用比較老的 CDH 的創業公司，鑑於其內嵌的就是 0.9版本，因此要格外注意這些問題。

0.10.0.0 是里程碑式的大版本，由於該版本引入了 Kafka Streams。從這個版本起，Kafka 正式升級成分佈式流處理平臺，雖然此時的 Kafka Streams 還基本不能線上部署使用。0.10 大版本包含兩個小版本：0.10.1 和 0.10.2，它們的主要功能變動都是在 Kafka Streams 組件上。若是你把 Kafka 用做消息引擎，實際上該版本並無太多的功能提高。
不過在個人印象中自 0.10.2.2 版本起，新版本 Consumer API 算是比較穩定了。若是你依然在使用 0.10 大版本，我強烈建議你至少升級到 0.10.2.2 而後使用新版本 Consumer API。還有個事情不得不提，0.10.2.2 修復了一個可能致使 Producer 性能下降的 Bug。基於性能的緣故你也應該升級到 0.10.2.2。

在 2017 年 6 月，社區發佈了 0.11.0.0 版本，引入了兩個重量級的功能變動：一個是提供冪等性 Producer API 以及事務（Transaction） API；
另外一個是對 Kafka 消息格式作了重構。前一個好像更加吸引眼球一些，畢竟 Producer 實現冪等性以及支持事務都是 Kafka 實現流處理結果正確性的基石。沒有它們，Kafka Streams 在作流處理時沒法向批處理那樣保證結果的正確性。固然一樣是因爲剛推出，此時的事務 API 有一些 Bug，不算十分穩定。另外事務 API 主要是爲 Kafka Streams 應用服務的，實際使用場景中用戶利用事務 API 自行編寫程序的成功案例並很少見
第二個重磅改進是消息格式的變化。雖然它對用戶是透明的，可是它帶來的深遠影響將一直持續。由於格式變動引發消息格式轉換而致使的性能問題在生產環境中家常便飯，因此你必定要謹慎對待 0.11 版本的這個變化。不得不說的是，這個版本中各個大功能組件都變得很是穩定了，國內該版本的用戶也不少，應該算是目前最主流的版本之一了。也正是由於這個緣故，社區爲 0.11 大版本特地推出了 3 個 Patch 版本，足見它的受歡迎程度。個人建議是，若是你對 1.0 版本是否適用於線上環境依然感到困惑，那麼至少將你的環境升級到0.11.0.3，由於這個版本的消息引擎功能已經很是完善了。

最後我合併說下 1.0 和 2.0 版本吧，由於在我看來這兩個大版本主要仍是 Kafka Streams的各類改進，在消息引擎方面並未引入太多的重大功能特性。Kafka Streams 的確在這兩個版本有着很是大的變化，也必須認可 Kafka Streams 目前依然還在積極地發展着。若是你是 Kafka Streams 的用戶，至少選擇 2.0.0 版本吧。

去年 8 月國外出了一本書叫 Kafka Streams in Action（中文版：《Kafka Streams 實戰》），它是基於 Kafka Streams 1.0 版本撰寫的。最近我用 2.0 版本去運行書中的例子，竟然不少都已經沒法編譯了，足見兩個版本變化之大。不過若是你在乎的依然是消息引擎，那麼這兩個大版本都是適合於生產環境的。

最後還有個建議，不論你用的是哪一個版本，都請儘可能保持服務器端版本和客戶端版本一致，不然你將損失不少 Kafka 爲你提供的性能優化收益。