Kafka实战(五) - Kafka的秘技"坂本"之争

只有顺应版本,才能成就王者不败神话

也是可否用好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.七、0.八、0.九、0.十、0.十一、1.0和2.0

3.1 版本代号:0.7

“上古”版本，不少人都没触过

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

该版本只提供最基础的消息队列功能，连副本机制都没有!

3.2 版本代号:0.8

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

在zk使用者中修复压缩消息的commit（）

正式引入了副本机制，至此Kafka成为了一个真正意义上完备的分布式高可靠消息队列解决方案。

有了副本机制，Kafka能比较好地作到消息无丢失

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

所谓的老版本是指当用它们的API开发生产者和消费者应用时
须要指定ZooKeeper的地址而非Broker的地址

老版生产者API，默认使用同步方式发送消息，可想而知其吞吐量不会高

虽然它也支持异步的方式，但实际场景中可能会形成消息的丢失

• 所以0.8.2.0版本社区引入了 新版本Producer API

即须要指定Broker地址的Producer。

建议是尽可能使用比较新的版本

3.3 版本代号:0.9

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版本，因此要格外注意这些问题。

3.4 版本代号: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。

3.5 版本代号:0.11

幂等性Producer / 事务（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 Streams 1.0版本撰写的。用2.0版本去运行书中的例子，竟然不少都已经没法编译了，足见两个版本变化之大。不过若是你在乎的依然是消息引擎，那么这两个大版本都是适合于生产环境的。

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

4 总结

每一个Kafka版本都有它恰当的使用场景和独特的优缺点，切记不要一味追求最新版本

不要成为最新版本的“小白鼠”

了解了各个版本的差别以后，必定可以根据本身的实际状况做出最正确的选择