大数据之kafka-05.讲聊聊Kafka的版本号

今天聊聊kafka版本号的问题，这个问题实在是过重要了，我以为甚至是往后可否用好kafka的关键。上一节咱们介绍了kafka的几种发行版，其实不管是哪一种kafka，本质上都内嵌了最核心的Apache kafka，也就是社区版kafka，那今天咱们就说说Apache kafka版本号的问题。在开始以前，先强调一下，后面出现的全部"版本"这个词都表示kafka具体的版本号，而非上一节中介绍kafka种类，这一点要切记。

那么如今可能会有这样的疑问，我为何要关心版本号的问题呢？直接使用最新版本不就行了吗？固然了，这的确是一种有效的版本选择的策略，但我想强调的是这种策略并不是在任何场景下都适用。若是你不了解各个版本之间的差别和功能变化，你怎么能准确地评判某kafka版本是否是知足你的业务需求呢？所以在深刻学习kafka以前，花些时间搞明白版本演进，其实是很是划算的一件事。

kafka版本命名

当前Apache kafka已经迭代到2.2版本，社区正在为2.3.0发版日期进行投票，相信2.3.0也会立刻发布。可是稍微有些使人吃惊的是，不少人对于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程序员隐退罢了。可能有点跑题了，可是无论怎么样，我依然建议你有空学一学python语言。

回到刚才的版本号讨论，如今你应该知道了对于kafka-2.11-2.1.1的提法，真正的kafka版本号是2.1.1，那么这个2.1.1又表示什么呢？前面的2表示大版本号，即major version；中间的1表示小版本号或者次版本号，即minor version；最后的1表示修订版本号，也就是patch号。kafka社区在发布1.0.0版本后特地写过一篇文章，宣布kafka版本命名规则正式从4位演进到3位，好比0.11.0.0版本就是4位版本号。

kafka版本演进

于kafka目前总共演进了7个大版本，分别是0.七、0.八、0.九、0.十、0.十一、1.0和2.0，其中的小版本和patch版本不少。哪些版本引入了哪些重大的功能改进？建议你最好作到如数家珍，由于这样不只令你在和别人交谈时显得很酷，并且若是你要向架构师转型或者已然是架构师，那么这些都是可以帮助你进行技术选型、架构评估的重要依据。

咱们先从0.7版本提及，实际上也没有什么可说的，这是最先开源时的上古版本了。这个版本只提供了最基础的消息队列功能，甚至连副本机制都没有，我实在想不出来有什么理由你要使用这个版本，所以若是有人要向你推荐这个版本，果断走开好了。

kafka从0.7时代演进到0.8以后正式引入了副本机制，至此kafka成为了一个真正意义上完备的分布式、高可靠消息队列解决方案。有了副本备份机制，kafka就可以比较好地作到消息无丢失。那时候生产和消费消息使用的仍是老版本客户端的api，所谓老版本是指当你使用它们的api开发生产者和消费者应用时，你须要指定zookeeper的地址而非broker的地址。

若是你如今尚不能理解这二者的区别也没有关系，我会在后续继续介绍它们。老版本的客户端有不少的问题，特别是生产者api，它默认使用同步方式发送消息，能够想到其吞吐量必定不会过高。虽然它也支持异步的方式，但实际场景中消息有可能丢失，所以0.8.2.0版本社区引入了新版本producer api，即须要指定broker地址的producer。

据我所知，国内依然有少部分用户在使用0.8.1.一、0.8.2版本。个人建议是尽可能使用比较新的版本，若是你不能升级大版本，我也建议你至少要升级到0.8.2.2这个版本，由于该版本中老版本消费者的api是比较稳定的。另外即便升级到了0.8.2.2，也不要使用新版本producer api，此时它的bug还很是的多。

时间来到了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.9新版本的consumer api。对于国内一些使用比较老的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；另外一个是对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版本吧。

去年8月国外出了一本书叫作kafka streams in action，中文译名：kafka streams实战，它是基于kafka streams1.0版本撰写的，可是用2.0版本去运行书中的不少例子，竟然不少都已经没法编译了，足见两个版本的差异之大。不过若是你在乎的依然是消息引擎，那么这两个大版本都是能够用于生产环境的。

最后还有个建议，不论你使用的是哪一个版本，都请尽可能保持服务器端版本和客户端版本一致，不然你将损失不少kafka为你提供的性能优化收益。