文章很長，建議收藏起來，慢慢讀！ Java 高併發 發燒友社群：瘋狂創客圈 奉上以下珍貴的學習資源：

• 免費贈送 經典圖書:《Java高併發核心程式設計（卷1）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

• 免費贈送 經典圖書:《Java高併發核心程式設計（卷2）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

• 免費贈送 經典圖書:《Netty Zookeeper Redis 高併發實戰》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

• 免費贈送 經典圖書:《SpringCloud Nginx高併發核心程式設計》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

• 免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取

推薦：入大廠 、做架構、大力提升Java 內功 的 精彩博文

Kafka原始碼分析2：Kafka產品選擇和Kafka版本選擇（史上最全）

首先來看Kafka三大產品應該如何選擇？

Kafka三大產品應該如何選擇？

Apache Kafka

Apache Kafka 是最“正宗”的 Kafka，自 Kafka 開源伊始，它便在 Apache 基金會孵化並最終畢業成為頂級專案，它也被稱為社群版 Kafka，也就是說，後面提到的發行版要麼是原封不動地繼承了 Apache Kafka，要麼是在此之上擴充套件了新功能，總之 Apache Kafka 是我們學習和使用 Kafka 的基礎

優點：是開發人數最多、版本迭代速度最快的 Kafka，當使用 Apache Kafka 碰到任何問題並提交問題到社群，社群都會比較及時地作出響應。

缺點：僅僅提供最最基礎的元件，特別是對於前面提到的 Kafka Connect 而言，社群版 Kafka 只提供一種聯結器，即讀寫磁碟檔案的聯結器，而沒有與其他外部系統互動的聯結器，在實際使用過程中需要自行編寫程式碼實現。另外 Apache Kafka 沒有提供任何監控框架或工具。顯然在線上環境不加監控肯定是不可行的，你必然需要藉助第三方的監控框架實現對 Kafka 的監控。好訊息是目前有一些開源的監控框架可以幫助用於監控 Kafka（比如 Kafka manager）。kafka eagle 也是非常不錯的監控軟體，好像也是國人寫的，一直在更新，而且不比kafka manager差（JMXTrans + InfluxDB + Grafana）

總而言之，如果你僅僅需要一個訊息引擎系統亦或是簡單的流處理應用場景，同時需要對系統有較大把控度，那麼我推薦你使用 Apache Kafka

Confluent Kafka

2014 年，Kafka 的 3 個創始人 Jay Kreps、Naha Narkhede 和饒軍離開 LinkedIn 創辦了 Confluent 公司，專注於提供基於 Kafka 的企業級流處理解決方案。

Confluent 公司它主要從事商業化 Kafka 工具開發，並在此基礎上釋出了 Confluent Kafka

Confluent Kafka 提供了一些 Apache Kafka 沒有的高階特性，跨資料中心備份、Schema 註冊中心以及叢集監控工具等

優點：

免費版：免費版包含了更多的聯結器，它們都是 Confluent 公司開發並認證過的，你可以免費使用它們，還包含 Schema 註冊中心和 REST proxy 兩大功能

企業版：開放 HTTP 介面的方式允許你通過網路訪問 Kafka 的各種功能，最有用的當屬跨資料中心備份和叢集監控兩大功能了。多個數據中心之間資料的同步以及對叢集的監控歷來是 Kafka 的痛點，Confluent Kafka 企業版提供了強大的解決方案幫助你“幹掉”它們

缺點：Confluent 公司暫時沒有發展國內業務的計劃，相關的資料以及技術支援都很欠缺，很多國內 Confluent Kafka 使用者甚至無法找到對應的中文文件，因此目前 Confluent Kafka 在國內的普及率是比較低的

一言以蔽之，如果你需要用到 Kafka 的一些高階特性，那麼推薦你使用 Confluent Kafka。

Cloudera/Hortonworks Kafka

Cloudera 提供的 CDH 和 Hortonworks 提供的 HDP 是非常著名的大資料平臺，裡面集成了目前主流的大資料框架，能夠幫助使用者實現從分散式儲存、叢集排程、流處理到機器學習、實時資料庫等全方位的資料處理。這兩款產品中的 Kafka 稱為 CDH Kafka 和 HDP Kafka

優點：這些大資料平臺天然集成了 Apache Kafka，通過便捷化的介面操作將 Kafka 的安裝、運維、管理、監控全部統一在控制檯中。所有的操作都可以在前端 UI 介面上完成，而不必去執行復雜的 Kafka 命令。另外這些平臺提供的監控介面也非常友好，你通常不需要進行任何配置就能有效地監控 Kafka

缺點：這樣做的結果是直接降低了你對 Kafka 叢集的掌控程度。畢竟你對下層的 Kafka 叢集一無所知。

另一個弊端在於它的滯後性。由於它有自己的釋出週期，因此是否能及時地包含最新版本的 Kafka 就成為了一個問題。比如 CDH 6.1.0 版本釋出時 Apache Kafka 已經演進到了 2.1.0 版本，但 CDH 中的 Kafka 依然是 2.0.0 版本，顯然那些在 Kafka 2.1.0 中修復的 Bug 只能等到 CDH 下次版本更新時才有可能被真正修復。

簡單來說，如果你需要快速地搭建訊息引擎系統，或者你需要搭建的是多框架構成的資料平臺且 Kafka 只是其中一個元件，那麼我推薦你使用這些大資料雲公司提供的 Kafka。

Apache Kafka版本命名

比如我們在官網上下載 Kafka 時，會看到這樣的版本：

難道 Kafka 版本號不是 2.11 或 2.12 嗎？

其實不然，前面的版本號是編譯 Kafka 原始碼的 Scala 編譯器版本。Kafka 伺服器端的程式碼完全由 Scala 語言編寫，Scala 同時支援面向物件程式設計和函數語言程式設計，用 Scala 寫成的原始碼編譯之後也是普通的“.class”檔案，因此我們說 Scala 是 JVM 系的語言。

現在你應該知道了對於 kafka-2.11-2.30 的提法，真正的 Kafka 版本號實際上是 2.3.0。那麼這個 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 版本是 0.10.2.2，你現在就知道了它的大版本是 0.10，小版本是 2，總共打了兩個大的補丁，Patch 號是 2。

假設碰到的 Kafka 版本是 2.5.0 ，你現在就知道了, 前面的 2 表示大版本號，即 Major Version；中間的 5 表示小版本號或次版本號，即 Minor Version；最後的 1 表示修訂版本號，也就是 Patch 號

Apache Kafka的版本演進

Kafka 目前總共演進了 7 個大版本，分別是 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中的小版本和 Patch 版本很多。哪些版本引入了哪些重大的功能改進？

0.7

這是個“上古”版本，只提供了基礎的訊息佇列功能，還沒有提供副本機制

0.8

新增瞭如下幾個重要特性：

1. Kafka 0.8.0，增加了副本機制，至此Kafka成為了一個真正意義上完備的分散式高可靠訊息佇列解決方案；
2. Kafka 0.8.2.0，consumer 的消費偏移位置 offset 由原來的儲存在 zookeeper 改為儲存在 kafka 本身（afka 定義了一個系統 topic，專用用來儲存偏移量的資料）；
3. Kafka 0.8.2.0，引入了新版本Producer API：新版本Producer API有點不同，一是連線Kafka方式上，舊版本的生產者及消費者API連線的是Zookeeper，而新版本則連線的是Broker；二是新版Producer採用非同步批量方式傳送訊息，比之前同步傳送訊息的效能有所提升。

新舊版本Producer API如下：

//舊版本
Producerkafka.javaapi.producer.Producer<K,V> 
 
//新版本
Producerorg.apache.kafka.clients.producer.KafkaProducer<K,V>

注：此版本的新版本producer api還不太穩定。

0.9

2015 年 11 月，社群正式釋出了 0.9.0.0 版本。

這是一個重量級的大版本更迭，0.9 大版本增加了基礎的安全認證 / 許可權功能，同時使用 Java 重寫了新版本消費者 API，另外還引入了 Kafka Connect 元件用於實現高效能的資料抽取。還有另一個好處是新版本 Producer API 在這個版本中算比較穩定了。如果你使用 0.9 作為線上環境不妨切換到新版本 Producer，這是此版本一個不太為人所知的優勢。

Kafka 0.9 是一個重大的版本迭代，增加了非常多的新特性，主要體現在三個方面：

1. 新版本Consumer API：Kafka 0.9.0使用java重寫了新版Consumer API，使用方式也是從連線Zookeeper切到了連線Broker；
2. 安全方面：在0.9.0之前，Kafka安全方面的考慮幾乎為0。Kafka 0.9.0 在安全認證、授權管理、資料加密等方面都得到了支援，包括支援Kerberos等；
3. Kafka Connect：Kafka 0.9.0 引入了新的元件 Kafka Connect ，用於實現Kafka與其他外部系統之間的資料抽取。

注：此時的新版本Consumer api還不大穩定，而0.9.0版本的Producer API已經比較穩定了；

0.10

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 已經比較穩定了，而且新版本的 Producer API 的效能也得到了提升，因此對於使用 0.10.x 大版本的使用者，建議使用或升級到 Kafka 0.10.2.2 版本。

0.11

2017 年 6 月，社群釋出了 0.11.0.0 版本

Kafka 0.11 是一個里程碑式的大版本，主要有兩個大的變更：

1. 提供冪等性 Producer API 以及事務（Transaction） API

   從這個版本開始支援Exactly-Once 語義即精準一次語義，主要是實現了Producer端的訊息冪等性，以及事務特性，這對於Kafka流式處理具有非常大的意義；

2. 對 Kafka 訊息格式做了重構

   Kafka 0.11另一個重大變更是Kafka訊息格式的重構（對使用者是透明的），主要為了實現Producer冪等性與事務特性，重構了投遞訊息的資料結構。這一點非常值得關注，因為Kafka 0.11之後的訊息格式發生了變化，所以我們要特別注意Kafka不同版本間訊息格式不相容的問題。

注：這個版本中各個大功能元件都變得非常穩定了，應該算是目前最主流的版本之一。

Producer 實現冪等性以及支援事務都是 Kafka 實現流處理結果正確性的基石。沒有它們，Kafka Streams 在做流處理時無法向批處理那樣保證結果的正確性。當然同樣是由於剛推出，此時的事務 API 有一些 Bug，不算十分穩定。另外事務 API 主要是為 Kafka Streams 應用服務的

第二個重磅改進是訊息格式的變化。雖然它對使用者是透明的，但是它帶來的深遠影響將一直持續。因為格式變更引起訊息格式轉換而導致的效能問題在生產環境中屢見不鮮，所以你一定要謹慎對待 0.11 版本的這個變化。不得不說的是，這個版本中各個大功能元件都變得非常穩定了，國內該版本的使用者也很多，應該算是目前最主流的版本之一了。

1.x

Kafka 1.x 更多的是Kafka Streams方面的改進，以及Kafka Connect的改進與功能完善等。但仍有兩個重要特性：

• 一是Kafka 1.0.0實現了磁碟的故障轉移，當Broker的某一塊磁碟損壞時資料會自動轉移到其他正常的磁碟上，Broker還會正常工作，這在之前版本中則會直接導致Broker宕機，因此Kafka的可用性與可靠性得到了提升；
• 二是Kafka 1.1.0開始支援副本跨路徑遷移，分割槽副本可以在同一Broker不同磁碟目錄間進行移動，這對於磁碟的負載均衡非常有意義。

2.x

Kafka 2.x 更多的也是Kafka Streams、Connect方面的效能提升與功能完善，以及安全方面的增強等。一個使用特性，Kafka 2.1.0開始支援ZStandard的壓縮方式，提升了訊息的壓縮比，顯著減少了磁碟空間與網路io消耗。

2.7.0

Apache Kafka 2.7.0 於2020年12月21日正式釋出，這個版本是目前 Kafka 最新穩定版本，大家可以根據需要自行決定是否需要升級到次版本，關於各個版本升級到 Apache Kafka 2.7.0 請參見《Upgrading to 2.7.0 from any version 0.8.x through 2.6.x》。

在這個版本中，社群仍然在推進從 Kafka 移除對 ZooKeeper 的依賴，比如這個版本在 KIP-497 裡面添加了可以修改 ISR 的 Broker 內部 API;在 KIP-500 裡面增加了自元數管理(Self-Managed Metadata Quorum)的 Raft 核心實現，這個也是去掉 Zookeeper 的一部分工作。現在在 Kafka 的原始碼裡面有一個名為 raft 的模組專門用於實現共識協議(consensus protocol)。在與控制器(Kafka 叢集中負責管理分割槽和副本狀態的 broker)的整合完成之前，有一個獨立的伺服器可以用來測試 Raft 實現的效能。

當然，為了取代 Zookeeper，還有更多的工作正在努力進行中，很多 KIP 正在積極開發中，以使得每個叢集能夠支援更多的分割槽、更簡單的操作和更嚴格的安全性。

關於客戶端版本：

kafka 支援多個語言的客戶端api，這裡只關注 java 客戶端。maven 的工程我們一般這樣引入 kafka 客戶端

<dependency>
	<groupId>org.apache.kafka</groupId>
	<artifactId>kafka_2.11</artifactId>
	<version>0.10.2.0</version>
</dependency>

這種會引入兩個依賴jar，分別是

• kafka-clients-0.10.2.0.jar
• kafka_2.11-0.10.2.0.jar

前者是官方推薦的java客戶端，後者是scala客戶端。呼叫方式有所不同。如果確定不使用 scala api，也可以用下面這種方式只包含java版本的客戶端。

<dependency>
	<groupId>org.apache.kafka</groupId>
	<artifactId>kafka-clients</artifactId>
	<version>0.10.2.0</version>
</dependency>

最後，給出一些建議：

• 遵循一個基本原則，Kafka客戶端版本和服務端版本應該保持一致，否則可能會遇到一些問題。
• 根據是否用到了Kafka的一些新特性來選擇，假如要用到Kafka生產端的訊息冪等性，那麼建議選擇Kafka 0.11 或之後的版本。
• 選擇一個自己熟悉且穩定的版本，如果說沒有比較熟悉的版本，建議選擇一個較新且穩定、使用比較廣泛的版本。

Kafka 版本是否升級應該如何考慮？

首先，看業務在使用當前Kafka版本是否有問題,是否有效能問題,
其次，當前版本特性是否滿足業務需求,是否需要新的Kafka特性
然後，檢視該當前版本是否還在迭代更新,以及迭代週期
最後，升級Kafka版開發人員所付出的人工成本和時間成本

不要成為最新版本的小白鼠， 如果確實想升級，也建議小範圍可控制之內再升級

參考文獻

https://www.cnblogs.com/start-from-zero/p/13430611.html

https://blog.csdn.net/lidazhou/article/details/95909496

https://www.jianshu.com/p/5bef1f9f74cd

http://www.louisvv.com/archives/2348.html

http://www.machengyu.net/tech/2019/09/22/kafka-version.html