Apache Kafka 1.0：为什么我们等了这么久？

Kafka 迎来 1.0.0 版本，正式告别四位数版本号!

Kafka 从首次发布之日起，已经走过了七个年头。从最开始的大规模消息系统，发展成为功能完善的分布式流式处理平台，用于发布和订阅、存储及实时地处理大规模流数据。来自世界各地的数千家公司在使用 Kafka，包括三分之一的 500 强公司。

Kafka 以稳健的步伐向前迈进，首先加入了复制功能和无边界的键值数据存储，接着推出了用于集成外部存储系统的 Connect API，后又推出了为实时应用和事件驱动应用提供原生流式处理能力的 Streams API，并于今年春季开始支持仅一次处理语义。如此广泛的应用和完备的功能以及如此悠久的历史，无一不在说明 Kafka 已经成为一款稳定的企业级产品。而更为激动人心的是，Kafka 现在正式迎来了 1.0.0 版本!

Kafka 1.0.0 发布的主要内容如下：

0.10.0 版本里开始引入的 Streams API 在 1.0.0 版本里继续演进，改进了 builder API(KIP-120)，新增了用于查看运行时活跃任务的 API(KIP-130)和用于聚合分区的 cogroup API(KIP-150)。增强的 print() 和 writeAsText() 方法让调试变得更容易(KIP-160)。其他更多信息可以参考 Streams 文档。

改进了 Connect 的度量指标(KIP-196)，新增了大量用于健康监测的度量指标(KIP-188)，并提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指标(KIP-168)。

支持 Java 9，实现更快的 TLS 和 CRC32C，加快了加密速度，降低了计算开销。

调整了 SASL 认证模块的错误处理逻辑(KIP-152)，原先的认证错误信息现在被清晰地记录到日志当中。

更好地支持磁盘容错(KIP-112)，更优雅地处理磁盘错误，单个 JBOD 上的磁盘错误不会导致整个集群崩溃。

0.11.0 版本中引入的幂等性生产者需要将 max.in.flight.requests.per.connection 参数设置为 1，这对吞吐量造成了一定的限制。而在 1.0.0 版本里，这个参数最大可以被设置为 5(KAFKA-5949)，极大提升了吞吐量范围。

关于新版本更多的变化可以查看发布说明：

https://dist.apache.org/repos/dist/release/kafka/1.0.0/RELEASE_NOTES.html

下载源代码：

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka-1.0.0-src.tgz

二进制包

Scala 2.11：

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.11-1.0.0.tgz

Scala 2.12：

https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.12-1.0.0.tgz

为此，特意联系了 Apache Kafka 项目董事，代码提交者王国璋。对于 Kafka 的 1.0 时代，他有什么想说的?

就在昨天 Apache Kafka 项目的 1.0.0 终于发布了，这标志着 Kafka 正式跨入了 1.0 时代。

之前很多人都问我们，为什么等了这么久啊?赶快推进到 1.0 版啊，我们公司的政策是开源软件必须至少要进入到 1.0 版之后才放心让我们用啊!：)确实，作为一个 2010 年创建，2011 年就加入到 Apache 开源软件基金会(ASF)，2012 年就从孵化器(Apache Incubator)毕业的“老项目”，我们却足足用了五年时间，直到 2017 年 11 月 1 日才发布到 1.0 版本，看上去好像真的太久了一点。

这当然不是因为在此之前 Kafka 的系统架构还不够稳定，也不是因为 Kafka 还没有得到足够多的用户支持：事实上，早在我们从 Incubator 毕业并发布 0.8 版本的时候，在当时除了 LinkedIn 之外的很多公司就已经开始广泛使用 Kafka。到了今年 Kafka 1.0.0 发布之前，Kafka 已经在全世界各个领域各大公司，从金融，零售，制造，运营，物流，新闻，运营商，到互联网领域等等(https://kafka.apache.org/powered-by)，覆盖超过三分之一的福布斯 500 强公司都在它们的大规模集群中使用着 Kafka。

回想起从 0.8 版本一路走过来的这几年，我也会问我自己，为什么我们等了这么久呢?

2012 年的时候我第一次在 LinkedIn 接触 Kafka 项目，那个时候 Kafka 的版本还是 0.7.2，我们在对外介绍 Kafka 项目的时候，还是以一个“分布式发布订阅消息队列系统”(Distributed Pub-Sub Messaging System)来称呼它。当时 Kafka 在 LinkedIn 的主要用途，就是干一件事情：把在线生成的各种大规模数据，从用户日志到系统指标，以最快的方式传递到后台的处理平台上，也就是各种数据仓库(Data Warehouse)工具和 Hadoop/HDFS。

那时候 Kafka 的设计理念是“虽然我很傻，但是我很快”：字节入，字节出，没有多余的处理操作，处理的数据也都还不是关键业务消息。直到 0.8 版本的发布，我们加入了一个重要的副本功能，有效防止了在各种灾难或错误情况下的丢数据情况，从此 Kafka 才开始在各大公司内部真正进入了实时数据存储处理的核心架构：要知道，丢失一个订货付款消息和丢失一个日志消息的代价，可是差太多了：)

就在那个时候，我们在参加各种 Kafka Meetup 上听取同行分享他们的使用心得，见到了越来越多不同的应用场景：有些公司不仅用 Kafka 来发布队列消息，也用来存储数据库备份文件作异地容灾，有些公司用 Kafka 来更新查询索引，有些公司用 Kafka 来实时处理在线业务，等等等等。Kafka 本身的数据模型定义：一个仅附加的写提前日志(append only WAL log)，其使用范围之广，实际上远远超出了我们一开始的预想。于是当时在 Kafka 组成员之间，开始讨论一个问题，那就是如果我们想要将 Kafka 扩展作为一个实时流数据平台(Stream Data Platform)，还需要做哪些事情。

记得当时我和组里的技术“大拿”，现在 Confluent 公司的联合创始人饶军聊天，也聊到在下一个阶段，大数据的发展将慢慢从“规模”之大(Volume)，转向“速度”之大(Velocity)：当我们已经有的足够体量的数据以后，下一个问题就是如何从拿在手上的数据中发现有用的信息，而且是越快越好。如此，传统的批量处理技术，包括数据仓库商务智能等等，就跟不上所要求的速度了。

接下来的时间，Kafka 进入到了高速发展时期：2014 年，我们发布了 0.9 版本，加入了另一个非常重要的安全功能，包括客户端身份验证，操作认证，传输加密等组件，和日志压缩功能(log compaction)进一步为 Kafka 成为实时关键业务数据的平台提升了空间。几乎在同时间，LinkedIn Kafka 组的核心成员创建了 Confluent。2015 年我自己也加入了 Confluent。那一年我们发布了 0.10 版本，加入了时间戳组件支持，并且进一步完善了 Kafka 作为一个实时流数据的核心平台架构的最后两片拼图：Kafka Connect(在 0.9 版本中加入)和 Kafka Streams。

至此，Kafka 可以帮助用户连接内部的各个在线系统与工具，各种实时数据：从最基本的日志流，到数据库采集流，到二次转换数据流，再到后台产生的实时更新数据流，都会通过 Kafka 进行存储，并且可以从系统架构内部的任何一“点”，快速的传输到其他任何一“点”。

而当这些实时数据已经全部整合到一个系统里面以后，实时流处理(stream processing)的使用，才有了用武之地：在此之前，由于数据分散在架构内部的各个角落，使得数据整合成为了流处理的一大前提，也是一大难题。但是在 Kafka 0.9 以及 0.10 以后，我们发现越来越多的用户开始把整合后的流数据作为源(source of truth)，而把数据库里面的表列，化为了这个数据源的一个不断更新的实时视图(materialized view)。这个潮流继续催生了事件回溯(event sourcing)，微服务(micro-services)等等基于实时流数据的系统框架和设计理念，使得流处理逐渐成为了新的主流。

而在这个新的主流下，Kafka 0.11 发布，我们加入了流处理的完全一次语义(exactly-once)支持，使得流处理的可靠性保证在用户面前简单到一个调参。在这个时候，回首看从 0.7.2 一路走过来的这些年，Kafka 社区的愿景才逐步清晰，那就是一个集成的，让用户可以简单有效的写入，读取，并处理流数据的平台。在这个愿景的完成度达到一个里程碑的时候，我们才决定在今天发布 1.0 版本。

很荣幸从 0.7.2 版本就开始参与 Kafka 的开发，那也是我自己第一次参与开源项目的贡献，期间学到了很多东西，但是更重要的就是在社区里面结识到的人。到今天 1.0.0 终于发布，还是感触良多。很多人说现如今 infrastructure software stack 潮起潮落，总是一浪更比一浪强，我倒是觉得对于这浪潮之中单独一个软件项目本身，尤其是一个开源项目而言，能够提出一个普适问题并给出一个简单优雅的解决方案，往往需要很长时间的琢磨。

关于 1.0.0 版本的新特性，我也不再赘述，欢迎大家阅读相关的发布公告。
https://www.confluent.io/blog/apache-kafka-goes-1-0/
https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces21