隻有順應版本,才能成就王者不敗神話
也是能否用好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系的語言.
回到剛才的版本号讨論。現在你應該知道了對于kafka-2.11-2.3.0的說法，真正的Kafka版本号實際上是2.3.0
- 前面的
2
- 中間的
3
- 最後的 表示修訂版本号，也就是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.7、0.8、0.9、0.10、0.11、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’配置參數以在日志檔案達到特定年齡後強制輪換它們
-
為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版本都有它恰當的使用場景和獨特的優缺點，切記不要一味追求最新版本
不要成為最新版本的“小白鼠”
了解了各個版本的差異之後，一定能夠根據自己的實際情況作出最正确的選擇
參考
- Kafka核心技術與實戰