Skip to content

kafka-versions.md

Latest commit

 

History

History
137 lines (82 loc) · 7.95 KB

kafka-versions.md

File metadata and controls

137 lines (82 loc) · 7.95 KB

Kafka的秘技 坂本 之争

0 前言

只有顺应版本，才能成就王者不败神话。也是能否用好Kafka的关键。不论是哪种Kafka，本质上都基于core Apache Kafka，那就来说说Apache Kafka版本号的问题。

1 缘何"在乎"你这版本号

直接使用最新版本不就好了吗？ 当然了!这的确是一种有效策略，这种策略并非在任何场景下都适用 如果不了解各个版本之间的差异和功能变化，怎么能够准确地评判某Kafka版本是不是满足你的业务需求呢？ 因此在深入学习Kafka之前，花些时间搞明白版本演进，实际上是非常划算的一件事。

2 版本的命名

当前Apache Kafka已经更迭至2.3

很多人对于Kafka的版本命名理解存在歧义

  • 在官网上下载Kafka时，会看到这样的版本：

于是有些同学就会纳闷，难道Kafka版本号不是2.11或2.12吗？ 并不呀，前面的版本号是编译Kafka源代码的Scala编译器的版本。Kafka服务器端的代码完全由Scala语言编写，Scala同时支持面向对象编程和函数式编程，用Scala写成的源代码编译之后也是普通的“.class”文件，因此我们说Scala是JVM系的语言.

事实上目前Java新推出的很多功能都是在不断向Scala语言靠近，比如Lambda表达式、函数式接口、val变量等 Kafka新版客户端代码完全由Java语言编写，于是有些人展开了“Java VS Scala”的大讨论，并从语言特性的角度尝试分析Kafka社区为什么放弃Scala转而使用Java重写客户端代码。 其实事情远没有那么复杂，仅仅是因为社区来了一批Java程序员而已，而以前老的Scala程序员隐退了

回到刚才的版本号讨论。现在你应该知道了对于kafka-2.11-2.3.0的说法，真正的Kafka版本号实际上是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版本命名

假设碰到的Kafka版本是0.10.2.2，你现在就知道了它的大版本是0.10，小版本是2，总共打了两个大的补丁，Patch号是2

3 Kafka版本演进

Kafka目前总共演进7个大版本：0.7、0.8、0.9、0.10、0.11、1.0和2.0

0.7

“上古”版本，很多人都没触过：

  • 引入取决于空间的保留设置
  • 添加可选的mx4j支持以通过http公开jmx
  • 在Kafka中介绍压缩功能
  • 提供默认生产者，用于接收来自STDIN的消息
  • 通过MBean公开总指标
  • 将py生产者升级到新的消息格式版本
  • 公开JMX操作以动态设置记录器级别
  • 基于时间的日志段推出

只提供最基础的MQ功能，副本机制都没！

0.8

  • kafka集群内副本支持
  • 支持多个数据目录
  • 在kafka asynchonous中进行请求处理
  • 改进Kafka内部指标
  • 添加'log.file.age'配置参数以在日志文件达到特定年龄后强制轮换它们
  • 公开JMX操作以动态设置记录器级别
  • 基于时间的日志段推出
  • 为Log子系统添加Performance Suite 在zk使用者中修复压缩消息的commit()

正式引入副本机制，至此Kafka成为真正意义上完备的分布式高可靠MQ解决方案。有了副本机制，就能较好做到消息无丢失。

那时生产和消费消息使用的还是老版本客户端API。

所谓老版本，指当用它们的API开发生产者和消费者应用时，需指定zk地址而非Broker地址。

老版生产者API，默认使用同步方式发送消息，可想而知其吞吐量不会高 虽然也支持异步，但实际可能造成消息丢失，为此0.8.2.0引入新版Producer API：

即需指定Broker地址的Producer。

建议尽量使用比较新的版本。

0.9

增加基础的安全认证/权限功能，使用Java重写新版本消费者API，引入Kafka Connect组件用于实现高性能的数据抽取。

新版Producer API在这版本算比较稳定。

如果你使用0.9作为线上环境不妨切换到新版本Producer，这是此版本一个不太为人所知的优势。但和0.8.2引入新API问题类似，不要使用新版本Consumer API，因为Bug超多的，绝对用到你崩溃。即使你反馈问题到社区，社区也不会管的，它会无脑地推荐你升级到新版本再试试，因此千万别用0.9的新版本Consumer API。对于国内一些使用比较老的CDH的创业公司，鉴于其内嵌的就是0.9版本，所以要格外注意这些问题。

0.10

引入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

幂等性Producer / 事务（Transaction）API

重构Kafka消息格式

Producer实现幂等性及支持事务都是Kafka实现流处理结果正确性的基石，没有它们，Kafka Streams在做流处理时无法向批处理那样保证结果的正确性。当然同样是由于刚推出，此时的事务API有一些Bug，不算十分稳定。

事务API主要是为Kafka Streams应用服务的，实际使用场景中用户利用事务API自行编写程序的成功案例并不多见。

第二个重磅改进是消息格式变化。虽然它对用户透明，但深远影响。因为格式变更引起消息格式转换而导致的性能问题在生产环境屡见不鲜，所以要谨慎对待这变化。该版本各大功能组件都变得非常稳定，国内该版本的用户也多，算目前最主流版本之一。也正是因此，社区为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 Streams 1.0版本撰写的。用2.0版本去运行书中的例子，居然很多都已经无法编译了，足见两个版本变化之大。不过如果你在意的依然是消息引擎，那么这两个大版本都是适合于生产环境的。

不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致，否则你将损失很多Kafka为你提供的性能优化收益。

4 总结

每个Kafka版本都有它恰当的使用场景和独特的优缺点，切记不要一味追求最新版本 不要成为最新版本的“小白鼠”。了解了各个版本的差异之后，一定能够根据自己的实际情况作出最正确的选择。