大數據之kafka-05.講聊聊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程序員隱退罷了。可能有點跑題了，可是無論怎麼樣，我依然建議你有空學一學python語言。

回到剛纔的版本號討論，如今你應該知道了對於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位版本號。

kafka版本演進

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

咱們先從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是比較穩定的。另外即便升級到了0.8.2.2，也不要使用新版本producer api，此時它的bug還很是的多。

時間來到了2015年11月，社區正式發佈了0.9.0.0版本，在我看來這是一個重量級的大版本更迭，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版本，因此要格外注意這些問題。

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；另外一個是對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 streams1.0版本撰寫的，可是用2.0版本去運行書中的不少例子，竟然不少都已經沒法編譯了，足見兩個版本的差異之大。不過若是你在乎的依然是消息引擎，那麼這兩個大版本都是能夠用於生產環境的。

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