1. Kafka 只是一個消息引擎系統嗎？
Apache Kafka 是消息引擎系統，也是一個分布式流處理平台（Distributed Streaming Platform）
Kafka 在設計之初就旨在提供三個方面的特性：
- 提供一套 API 實現生產者和消費者
- 降低網絡傳輸和磁盤存儲開銷
- 實現高伸縮性架構
批處理：批量處理冷數據，單個處理數據量大
流處理：處理在線，實時產生的數據，單次處理的數據量小，但處理速度更快
流處理要最終替代它的“兄弟”批處理需要具備兩點核心優勢：
- 要實現正確性，實現正確性是流處理能夠匹敵批處理的基石
- 提供能夠推導時間的工具。
正確性一直是批處理的強項，而實現正確性的基石則是要求框架能提供精確一次處理語義，即處理一條消息有且只有一次機會能夠影響系統狀態。目前主流的大數據流處理框架都宣稱實現了精確一次處理語義，但這是有限定條件的，即它們只能實現框架內的精確一次處理語義，無法實現端到端的。
l Kafka Streams 正是它提供了 Kafka 實時處理流數據的能力
l Kafka Connect 通過一個個具體的連接器（Connector），串聯起上下游的外部系統
2. apache Kafka 流處理平台主要組件介紹
Kafka Streams 正是它提供了 Kafka 實時處理流數據的能力
Kafka Connect 通過一個個具體的連接器（Connector），串聯起上下游的外部系統
3.不同版本間的Kafka應該如何選擇？
1. 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
2. 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。
3. 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。
4. Kafka版本命名
前面的版本號是編譯 Kafka 源代碼的 Scala 編譯器版本（2.12）
真正的 Kafka 版本號實際上是 2.5.0。那么這個 2.5.0 又表示什么呢？前面的 2 表示大版本號，即 Major Version；中間的 5 表示小版本號或次版本號，即 Minor Version；最后的 1 表示修訂版本號，也就是 Patch 號
5.Kafka的版本引進
Kafka 目前總共演進了 7 個大版本，分別是 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中的小版本和 Patch 版本很多。哪些版本引入了哪些重大的功能改進？
0.7
這是最早開源時的“上古”版本了，以至於我也從來都沒有接觸過。這個版本只提供了最基礎的消息隊列功能。甚至連副本機制都沒有
0.8
Kafka 從 0.7 時代演進到 0.8 之后正式引入了副本機制，至此 Kafka 成為了一個真正意義上完備的分布式高可靠消息隊列解決方案。有了副本備份機制，Kafka 就能夠比較好地做到消息無丟失。那時候生產和消費消息使用的還是老版本的客戶端 API，所謂的老版本是指當你用它們的 API 開發生產者和消費者應用時，你需要指定 ZooKeeper 的地址而非 Broker 的地址。
老版本客戶端有很多的問題，特別是生產者 API，它默認使用同步方式發送消息，可以想見其吞吐量一定不會太高。雖然它也支持異步的方式，但實際場景中可能會造成消息的丟失，因此 0.8.2.0 版本社區引入了新版本 Producer API，即需要指定 Broker 地址的 Producer.如果要使用0.8的版本至少要升級到 0.8.2.2 這個版本，因為該版本中老版本消費者 API 是比較穩定的。另外即使你升到了 0.8.2.2，也不要使用新版本 Producer API，此時它的 Bug 還非常多
0.9
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.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 算是比較穩定了。並且0.10.2.2 修復了一個可能導致 Producer 性能降低的 Bug
0.11
2017 年 6 月，社區發布了 0.11.0.0 版本，引入了兩個重量級的功能變更：
- 提供冪等性 Producer API 以及事務（Transaction） API
- 對 Kafka 消息格式做了重構
Producer 實現冪等性以及支持事務都是 Kafka 實現流處理結果正確性的基石。沒有它們，Kafka Streams 在做流處理時無法向批處理那樣保證結果的正確性。當然同樣是由於剛推出，此時的事務 API 有一些 Bug，不算十分穩定。另外事務 API 主要是為 Kafka Streams 應用服務的
第二個重磅改進是消息格式的變化。雖然它對用戶是透明的，但是它帶來的深遠影響將一直持續。因為格式變更引起消息格式轉換而導致的性能問題在生產環境中屢見不鮮，所以你一定要謹慎對待 0.11 版本的這個變化。不得不說的是，這個版本中各個大功能組件都變得非常穩定了，國內該版本的用戶也很多，應該算是目前最主流的版本之一了。
1.0 和 2.0
兩個大版本主要還是 Kafka Streams 的各種改進，在消息引擎方面並未引入太多的重大功能特性。如果你是 Kafka Streams 的用戶，至少選擇 2.0.0 版本吧。
思考
Kafka 版本是否升級應該如何考慮？
首先，看業務在使用當前Kafka版本是否有問題,是否有性能問題,
其次，當前版本特性是否滿足業務需求,是否需要新的Kafka特性
然后，查看該當前版本是否還在迭代更新,以及迭代周期
最后，升級Kafka版開發人員所付出的人工成本和時間成本
不要成為最新版本的小白鼠， 如果確實想升級，也建議小范圍可控制之內再升級