Closed geekyouth closed 2 years ago
原文地址 http://www.louisvv.com/archives/2348.html
在今年 1 月 25 号，Kafka 发布了 2.3.0 版本，当我点击下载的时候，会看到如下图所示的版本
有些人会误将 Scala 版本看作是 Kafka 版本，那么就来解释一下这个版本号
2.11/2.12 代表着 Kafka 源代码的 Scala 编译器版本，Kafka 服务器端代码完全由 Scala 语音编写，说到 Scala 就提两句，Scala 与 Java 相同都是 JVM 系的语言，它同时支持面向对象和函数式编程
Java 的新功能， 也在慢慢的向着 Scala 进行靠近，例如 Lambda 表达式，函数式接口，val 变量等
但 Kafka 新版客户端代码完全由 Java 语言编写，当然，不是 Scala 不行了，而是社区找来了一批 Java 程序员而已，而之前的 Scala 程序员隐退罢了
说完了前面 Scala 编译器版本，来说一下后面的 2.3.0
事实上，后面的才是 Kafka 的版本号
其中 2 代表着大版本号，即 Major Version
中间的 3 代表着小版本号或次版本号，即 Minor Version
最后的 0 代表着修订版本号或补丁，也就是 Patch 号
Kafka 社区在发不了 1.0.0 版本后，特意写了一篇文章，宣布 Kafka 版本命名规则从 4 位演进到 3 位，比如 0.11.0.0 版本就是 4 位版本号
关于老一代的四位版本号，和 3 位相似，例如 0.10.2.2，0.10 代表版本号，第一个 2 代表小版本是 2，第二个 2 代表总共有两个大的补丁，Patch 号位 2
说完了版本号，我们去回顾一下 Kafka 的版本演进
Kafka 目前经历了 7 个大版本，0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中小版本与 Patch 版本很多就不一一列举
在上面的 7 个大版本中，在哪个版本进行了重大的改进，来好好看一下
这是个 “上古” 版本，只提供了基础的消息队列功能，还没有提供副本机制
正式引入了副本机制，至此 Kafka 成为了一个真正意义上完备的分布式高可靠消息队列解决方案
有了副本备份机制，Kafka 就能够比较好地做到消息无丢失，那时候生产和消费消息使用的还是老版本的客户端 API，所谓的老版本是指当你用它们的 API 开发生产者和消费者应用时，你需要指定 ZooKeeper 的地址而非 Broker 的地址
关于老版本的客户端 API 有很多的问题，尤其是生产者 API，它默认使用同步的方式进行发送消息，这种方式吞吐量不会太高，虽然它也支持异步的方式，但在实际生产环境上可能会发生数据丢失的情况
因此，在 0.8.2.0 版本中，引入了新版本 Producer API
在国内还有少数人在使用 0.8.1.1 和 0.8.2 版本，因为各种各样的理由不能升级大版本，但还是建议升级到 0.8.2.2 这个版本，因为该版本中的老版消费者 API 还是比较稳定的，当你升级到 0.8.2.2 这个版本也不要使用新的 API，因为 BUG 很多
2015 年 11 月，社区正式发布了 0.9.0.0 版本，这是个重量级的版本更迭
0.9 版本中添加了基础的安全认证 / 权限，同时使用 Java 重写了新版本 Consumer API，另外还引入了 Kafka Connect 组件用于实现高性能的数据抽取
还有另一个重点在 0.9 版本，是新版本 Producer API 在这个版本中算比较稳定了
关于 0.9 版本有一个问题，就是 0.9 版的 Consumer API BUG 超多，即使提到社区也不会有人管，所以千万别用！
国内一些使用比较老的 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 以及事务（Transaction） 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 版本吧
最后还有个建议，不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致，否则你将损失很多 Kafka 为你提供的性能优化收益
❤
geekyouth
commented
4 years ago geekyouth
commented
4 years ago
原文地址 http://www.louisvv.com/archives/2348.html
在今年 1 月 25 号，Kafka 发布了 2.3.0 版本，当我点击下载的时候，会看到如下图所示的版本
有些人会误将 Scala 版本看作是 Kafka 版本，那么就来解释一下这个版本号
2.11/2.12
2.11/2.12 代表着 Kafka 源代码的 Scala 编译器版本，Kafka 服务器端代码完全由 Scala 语音编写，说到 Scala 就提两句，Scala 与 Java 相同都是 JVM 系的语言，它同时支持面向对象和函数式编程
Java 的新功能， 也在慢慢的向着 Scala 进行靠近，例如 Lambda 表达式，函数式接口，val 变量等
但 Kafka 新版客户端代码完全由 Java 语言编写，当然，不是 Scala 不行了，而是社区找来了一批 Java 程序员而已，而之前的 Scala 程序员隐退罢了
2.3.0
说完了前面 Scala 编译器版本，来说一下后面的 2.3.0
事实上，后面的才是 Kafka 的版本号
其中 2 代表着大版本号，即 Major Version
中间的 3 代表着小版本号或次版本号，即 Minor Version
最后的 0 代表着修订版本号或补丁，也就是 Patch 号
Kafka 社区在发不了 1.0.0 版本后，特意写了一篇文章，宣布 Kafka 版本命名规则从 4 位演进到 3 位，比如 0.11.0.0 版本就是 4 位版本号
关于老一代的四位版本号，和 3 位相似，例如 0.10.2.2，0.10 代表版本号，第一个 2 代表小版本是 2，第二个 2 代表总共有两个大的补丁，Patch 号位 2
Kafka 版本演进
说完了版本号，我们去回顾一下 Kafka 的版本演进
Kafka 目前经历了 7 个大版本，0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中小版本与 Patch 版本很多就不一一列举
在上面的 7 个大版本中，在哪个版本进行了重大的改进，来好好看一下
0.7 版本
这是个 “上古” 版本，只提供了基础的消息队列功能，还没有提供副本机制
0.8 版本
正式引入了副本机制，至此 Kafka 成为了一个真正意义上完备的分布式高可靠消息队列解决方案
有了副本备份机制，Kafka 就能够比较好地做到消息无丢失，那时候生产和消费消息使用的还是老版本的客户端 API，所谓的老版本是指当你用它们的 API 开发生产者和消费者应用时，你需要指定 ZooKeeper 的地址而非 Broker 的地址
关于老版本的客户端 API 有很多的问题，尤其是生产者 API，它默认使用同步的方式进行发送消息，这种方式吞吐量不会太高，虽然它也支持异步的方式，但在实际生产环境上可能会发生数据丢失的情况
因此，在 0.8.2.0 版本中，引入了新版本 Producer API
在国内还有少数人在使用 0.8.1.1 和 0.8.2 版本，因为各种各样的理由不能升级大版本，但还是建议升级到 0.8.2.2 这个版本，因为该版本中的老版消费者 API 还是比较稳定的，当你升级到 0.8.2.2 这个版本也不要使用新的 API，因为 BUG 很多
0.9 版本
2015 年 11 月，社区正式发布了 0.9.0.0 版本，这是个重量级的版本更迭
0.9 版本中添加了基础的安全认证 / 权限，同时使用 Java 重写了新版本 Consumer API，另外还引入了 Kafka Connect 组件用于实现高性能的数据抽取
还有另一个重点在 0.9 版本，是新版本 Producer API 在这个版本中算比较稳定了
关于 0.9 版本有一个问题，就是 0.9 版的 Consumer API BUG 超多，即使提到社区也不会有人管，所以千万别用！
国内一些使用比较老的 CDH 的创业公司，鉴于其内嵌的就是 0.9 版本，所以要格外注意这问题
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 大版本，我强烈建议你至少升级到 0.10.2.2 然后使用新版本 Consumer API
还有个事情不得不提，0.10.2.2 修复了一个可能导致 Producer 性能降低的 Bug。基于性能的缘故你也应该升级到 0.10.2.2
0.11 版本
在 2017 年 6 月，社区发布了 0.11.0.0 版本，引入了两个重量级的功能变更：一个是提供幂等性 Producer API 以及事务（Transaction） 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 版本
合并说下 1.0 和 2.0 版本吧，因为这两个大版本主要还是 Kafka Streams 的各种改进，在消息引擎方面并未引入太多的重大功能特性
Kafka Streams 的确在这两个版本有着非常大的变化，也必须承认 Kafka Streams 目前依然还在积极地发展着，如果你是 Kafka Streams 的用户，至少选择 2.0.0 版本吧
最后还有个建议，不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致，否则你将损失很多 Kafka 为你提供的性能优化收益