文章很长，建议收藏起来，慢慢读！ 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