聊聊Kafka的版本号

​ 这篇文章带大家了解一下 Kafka 各个版本之间的差异和功能变化，帮助大家在未来选择时，能够准确地评判某 Kafka 是不是满足业务的需求。

Kafka 版本命名

​ 对于下面的版本，该如果理解呢？

​ 前面的版本号Scala 2.11 是编译 Kafka 源代码的 Scala 编译器版本。Kafka 的服务端的代码完全由 Scala 语言编写的，Scala 同时支持面向对象编程和函数式编程，用 Scala 写成的源代码编译之后也是普通的 “.class” 文件，因此说 Scala 是JVM 系的语言，它的很多设计思想都是为人称道的。

​ 真正的 Kafka 版本号实际上是 2.1.1。前面的 2 表示大版本号，即 Major Version；中间的 1 表示小版本号或次版本号，即 Minor Version；最后的 1 表示修订版本号，也就是 Patch 号。Kafka社区在发布1.0.0版本后特意写过一篇文章，宣布Kafka版本命名规则正式从4位演进到3位，比如0.11.0.0版本就是4位版本号。假设以后碰到的 Kafka 版本号是 0.10.2.2，就应该知道它的大版本号是 0.10，小版本号是 2，总共打了两个大的补丁，Patch 号是 2。

Kafka 版本演进

​ Kafka 演进了多个版本，这里我们介绍 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中的小版本和 Patch 版本很多。哪些版本引入了哪些重大的功能改进？这些最好做到如数家珍，这样可以令你在未来无论是与人交谈还是技术选型、架构评估时，都可以作为重要依据。

​ 先从 0.7 版本说起，这是最早开源的 “上古” 版本，只提供了最基础的消息队列功能，连副本机制都没有，对于这个版本的 Kafka 没有任何理由使用。

​ Kafka 演进道 0.8 版本之后正式引入了副本机制，至此 Kafka 成为了一个真正意义上完备的分布式可靠消息队列解决方案。有了副本备份机制，Kafka 就能够比较好地做到消息无丢失。那时候生产和消费消息还是使用老版本的客户端 API，所谓的老版本是指当你用它们的 API 开发生产者和消费者应用时，需要制定 ZooKeeper 的地址而非 Broker 的地址。

​ 老版本客户端有很多问题，特别是生产者 API，它默认使用同步发送消息，古其吞吐量并不是很高。虽然它也支持异步的方法，但实际场景中可能会造成消息的丢失，因此 0.8.2.0 版本社区引入了新版本 Producer API，即需要指定 Broker 地址的 Producer。

​ 目前国内任然有少部分用户在使用 0.8.1.1、0.8.2 版本。我的建议是尽量使用比较新的版本。如果不能升级大版本，至少也要升级到 0.8.2.2 版本，因为该版本老版消费者 API 是比较稳定的。即时你升级到了 0.8.2.2 版本，也不要使用新版本的 Producer API，此时它的 Bug 还非常多。

​ 再后来，社区发布了 0.9.0.0 版本。0.9 大版本增加了基础的安全认证/权限功能，同时使用 Java 重写了新版本消费者 API，另外还引入了 Kafka Connect 组件用于实现高性能的数据抽取。这个版本的另一个好处，那就是新版本的 Producer API 在这个版本算比较稳定了。如果你使用 0.9 作为线上环境，不妨切换到新版本 Producer，这个此版本一个鲜为人知的优势。但由于重写新版本消费者 API，这个版本的 Consumer API 的 Bug 非常多，绝对用到你崩溃，因此千万不要使用 0.9 的新版本 Consumer API。

​ 0.10.0.0 是里程碑式的大版本，因为该版本引入了 Kafka Streamss。从该版本起，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，此版本还修复了一个可能导致 Producer 性能降低的 Bug，故出于性能的考虑也应该升级到该版本。

​ 在 0.11.0.0 版本，引入了两个重量级的功能变更：一个是提供幂等性 Producer API 和事务 API；另一个是对 Kafka 消息格式做了重构。

​ 相对来说，前一个更为重要，毕竟 Producer 实现幂等性以及支持事务都是 Kafka 实现流处理结果正确的基石。没有它们，Kafka Streams 在做流处理时无法像批处理那样保证结果的正确性。当然同样是刚推出，此时的事务 API 有一些 Bug，不算十分稳定。另外事务API 主要是为 Kafka Streams 应用服务的，实际使用场景中用户利用事务 API 自行编写程序的成功案例并不多。

​ 第二个改进是对消息格式的变化。虽然它对用户是透明的，但是它带来的深远影响将一直持续。因为格式变更引起消息格式转换而导致的性能问题在生产环境中屡见不鲜，所以你一定要谨慎对待0.11版本的这个变化。在这个版本中，各大功能组件都变得十分稳定了，国内该版本的用户也很多，算是目前最主流的版本之一。如果你对1.0版本是否适用于线上环境依然感到困惑，那么至少将你的环境升级到0.11.0.3，因为这个版本的消息引擎功能已经非常完善了。

​ 最后我合并说下1.0和2.0版本吧，因为在我看来这两个大版本主要还是Kafka Streamss的各种改进，在消息引擎方面并未引入太多的重大功能特性。Kafka Streamss的确在这两个版本有着非常大的变化，也必须承认Kafka Streamss目前依然还在积极地发展着。如果你是Kafka Streamss的用户，至少选择2.0.0版本吧。

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

小结

​ 现在对如何选择合适的 Kafka 你肯定能做到心中有数了，每个 Kafka 版本都有它恰当的使用场景和独特的优缺点，切记不要一味追求最新版本。

​ 下面做个简短的总结：

• 0.7 版本：只提供最基础的消息队列功能。
• 0.8 版本：引入副本机制，至此 Kafka 成为了一个真正意义上完备的分布式高可靠消息队列解决方案。
• 0.9.0.0 版本：增加了基础的安全认证/权限功能；使用 Java 重写了新版本消费者 API；引入了 Kafka Connect 组件。
• 0.10.0.0 版本：引入了 Kafka Streams，正式升级为分布式流处理平台。
• 0.11.0.0 版本：提供了幂等性 Producer API 以及事务 API；对 Kafka 消息格式做了重构。
• 1.0 和 2.0 版本：主要还是 Kafka Streamss 的各种改进。