文章很長，建議收藏起來，慢慢讀！ Java 高並發 發燒友社群：瘋狂創客圈 奉上以下珍貴的學習資源：
-
免費贈送 經典圖書:《Java高並發核心編程（卷1）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《Java高並發核心編程（卷2）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《Netty Zookeeper Redis 高並發實戰》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《SpringCloud Nginx高並發核心編程》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取
推薦：入大廠 、做架構、大力提升Java 內功 的 精彩博文
| 入大廠 、做架構、大力提升Java 內功 必備的精彩博文 | 2021 秋招漲薪1W + 必備的精彩博文 |
|---|---|
| 1：Redis 分布式鎖 （圖解-秒懂-史上最全） | 2：Zookeeper 分布式鎖 （圖解-秒懂-史上最全） |
| 3: Redis與MySQL雙寫一致性如何保證？ （面試必備） | 4: 面試必備：秒殺超賣 解決方案 （史上最全） |
| 5:面試必備之：Reactor模式 | 6: 10分鍾看懂， Java NIO 底層原理 |
| 7:TCP/IP（圖解+秒懂+史上最全） | 8：Feign原理 （圖解） |
| 9:DNS圖解（秒懂 + 史上最全 + 高薪必備） | 10：CDN圖解（秒懂 + 史上最全 + 高薪必備） |
| 11: 分布式事務（ 圖解 + 史上最全 + 吐血推薦 ） | 12：seata AT模式實戰（圖解+秒懂+史上最全） |
| 13：seata 源碼解讀（圖解+秒懂+史上最全） | 14：seata TCC模式實戰（圖解+秒懂+史上最全） |
| Java 面試題 30個專題 , 史上最全 , 面試必刷 | 阿里、京東、美團... 隨意挑、橫着走！！！ |
|---|---|
| 1： JVM面試題（史上最強、持續更新、吐血推薦） | 2：Java基礎面試題（史上最全、持續更新、吐血推薦 |
| 3：架構設計面試題 （史上最全、持續更新、吐血推薦） | 4：設計模式面試題 （史上最全、持續更新、吐血推薦） |
| 17、分布式事務面試題 （史上最全、持續更新、吐血推薦） | 一致性協議 （史上最全） |
| 29、多線程面試題（史上最全） | 30、HR面經，過五關斬六將后，小心陰溝翻船！ |
| 9.網絡協議面試題（史上最全、持續更新、吐血推薦） | 更多專題， 請參見【 瘋狂創客圈 高並發 總目錄 】 |
| SpringCloud 精彩博文 | |
|---|---|
| nacos 實戰（史上最全） | sentinel （史上最全+入門教程） |
| SpringCloud gateway （史上最全） | 更多專題， 請參見【 瘋狂創客圈 高並發 總目錄 】 |
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
新增了如下幾個重要特性：
- Kafka 0.8.0，增加了副本機制，至此Kafka成為了一個真正意義上完備的分布式高可靠消息隊列解決方案；
- Kafka 0.8.2.0，consumer 的消費偏移位置 offset 由原來的保存在 zookeeper 改為保存在 kafka 本身（afka 定義了一個系統 topic，專用用來存儲偏移量的數據）；
- 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 是一個重大的版本迭代，增加了非常多的新特性，主要體現在三個方面：
- 新版本Consumer API：Kafka 0.9.0使用java重寫了新版Consumer API，使用方式也是從連接Zookeeper切到了連接Broker；
- 安全方面：在0.9.0之前，Kafka安全方面的考慮幾乎為0。Kafka 0.9.0 在安全認證、授權管理、數據加密等方面都得到了支持，包括支持Kerberos等；
- 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 是一個里程碑式的大版本，主要有兩個大的變更：
-
提供冪等性 Producer API 以及事務（Transaction） API
從這個版本開始支持Exactly-Once 語義即精准一次語義，主要是實現了Producer端的消息冪等性，以及事務特性，這對於Kafka流式處理具有非常大的意義；
-
對 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