只有順應版本,才能成就王者不敗神話
也是能否用好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.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'配置參數以在日誌文件達到特定年齡後強制輪換它們
- 公開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版本都有它恰當的使用場景和獨特的優缺點，切記不要一味追求最新版本
不要成爲最新版本的“小白鼠”
瞭解了各個版本的差異之後，一定能夠根據自己的實際情況作出最正確的選擇