由浅到深学习kafka(四):kafka的版本号与版本演进

上篇文章说了说Kafka的种类,传送门:由浅到深学习kafka(三):kafka的种类

今天来聊一聊Kafka的版本号与它的版本演进

在今年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为你提供的性能优化收益

那么今天关于Kafka的版本和版本演进就到这里了,我们下篇文章见~


亲,看完了,点个赞呐!!!!

赫墨拉

我是一个喜爱大数据的小菜鸡,这里是我分享我的成长和经历的博客

You may also like...

4 Responses

  1. byx313说道:

    多谢老哥整理分享!

  2. byx313说道:

    “因此,在0.8.2.0版本中,引入了新版本Producer API,需要指定ZooKeeper的地址而非Broker的地址”
    这个写错了吧?在0.8.2的producer是指定broker的

  3. mozilla说道:

    写的很好,解答了我对于版本的疑惑。

mozilla进行回复 取消回复

电子邮件地址不会被公开。