Kafka實戰(五) - Kafka的祕技"阪本"之爭

只有順應版本,才能成就王者不敗神話

也是可否用好Kafka的關鍵。

不管是哪一種Kafka，本質上都基於core Apache Kafka

那就來講說Apache Kafka版本號的問題

1 緣何"在意"你這版本號

直接使用最新版本不就行了嗎？

固然了!這的確是一種有效策略，這種策略並不是在任何場景下都適用

若是不瞭解各個版本之間的差別和功能變化，怎麼可以準確地評判某Kafka版本是否是知足你的業務需求呢？

所以在深刻學習Kafka以前，花些時間搞明白版本演進，其實是很是划算的一件事。

2 版本的命名

當前Apache Kafka已經更迭至2.3

不少人對於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程序員隱退了

回到剛纔的版本號討論。如今你應該知道了對於kafka-2.11-2.3.0的說法，真正的Kafka版本號其實是2.3.0

• 前面的2表示大版本號，即Major Version
• 中間的3表示小版本號或次版本號，即Minor Version
• 最後的0表示修訂版本號，也就是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

3 Kafka版本演進

Kafka目前總共演進了7個大版本，分別是0.七、0.八、0.九、0.十、0.十一、1.0和2.0

3.1 版本代號:0.7

「上古」版本，不少人都沒觸過

• 引入取決於空間的保留設置
• 添加可選的mx4j支持以經過http公開jmx
• 在Kafka中介紹壓縮功能
• 提供默認生產者，用於接收來自STDIN的消息
• 經過MBean公開總指標
• 將python生產者升級到新的消息格式版本
• 公開JMX操做以動態設置記錄器級別
• 基於時間的日誌段推出

該版本只提供最基礎的消息隊列功能，連副本機制都沒有!

3.2 版本代號:0.8

• kafka集羣內副本支持
• 支持多個數據目錄
• 在kafka asynchonous中進行請求處理
• 改進Kafka內部指標
• 添加'log.file.age'配置參數以在日誌文件達到特定年齡後強制輪換它們
• 公開JMX操做以動態設置記錄器級別
• 基於時間的日誌段推出
• 爲Log子系統添加Performance Suite 在zk使用者中修復壓縮消息的commit（）

正式引入了副本機制，至此Kafka成爲了一個真正意義上完備的分佈式高可靠消息隊列解決方案。

有了副本機制，Kafka能比較好地作到消息無丟失

那時生產和消費消息使用的仍是老版本客戶端API

> 所謂的老版本是指當用它們的API開發生產者和消費者應用時 > 須要指定ZooKeeper的地址而非Broker的地址

老版生產者API，默認使用同步方式發送消息，可想而知其吞吐量不會高

雖然它也支持異步的方式，但實際場景中可能會形成消息的丟失

• 所以0.8.2.0版本社區引入了 新版本Producer API 即須要指定Broker地址的Producer。

建議是儘可能使用比較新的版本

3.3 版本代號:0.9

0.9大版本增長了基礎的安全認證/權限功能，同時使用Java重寫了新版本消費者API，另外還引入了Kafka Connect組件用於實現高性能的數據抽取

新版本Producer API在這個版本中算比較穩定了

> 若是你使用0.9做爲線上環境不妨切換到新版本Producer，這是此版本一個不太爲人所知的優點。但和0.8.2引入新API問題相似，不要使用新版本Consumer API，由於Bug超多的，絕對用到你崩潰。即便你反饋問題到社區，社區也不會管的，它會無腦地推薦你升級到新版本再試試，所以千萬別用0.9的新版本Consumer API。對於國內一些使用比較老的CDH的創業公司，鑑於其內嵌的就是0.9版本，因此要格外注意這些問題。

3.4 版本代號:0.10

該版本引入了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。

3.5 版本代號:0.11

冪等性Producer / 事務（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版本

基於Kafka Streams 1.0版本撰寫的。用2.0版本去運行書中的例子，竟然不少都已經沒法編譯了，足見兩個版本變化之大。不過若是你在乎的依然是消息引擎，那麼這兩個大版本都是適合於生產環境的。

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

4 總結

每一個Kafka版本都有它恰當的使用場景和獨特的優缺點，切記不要一味追求最新版本

不要成爲最新版本的「小白鼠」

瞭解了各個版本的差別以後，必定可以根據本身的實際狀況做出最正確的選擇