重磅发布：Kafka迎来1.0.0版本，正式告别四位数版本号

编辑 | Natalie & Vincent

AI 前线导语：Kafka 现在正式迎来了 1.0.0 版本！

更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）

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

正值 Kafka 1.0.0 正式版本发布之际，我们梳理了一下公众号上已发布的 Kafka 技术干货，并选出了部分精华文章，希望能帮助大家温故而知新。

崛起的 Kafka

Kafka 起初是由 LinkedIn 公司开发的一个分布式的消息系统，后成为 Apache 的一部分，它使用 Scala 编写，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Apache Storm、Spark 等都支持与 Kafka 集成。

随着微服务的流行，很多公司都在尝试将现有的系统进行架构升级。促成 Movio 公司架构改造的一项关键技术就是 Kafka 消息队列。

Kafka 作为分布式消息队列，在可靠性和可扩展性方面有非常大的优势。它不仅成为了 Movio 公司基础架构的关键组成部分，还为正在创建的系统架构提供了依据。

本文译自 Braedon Vickers 发布在 Movio 上的一篇文章，详尽地探讨了在微服务架构升级的过程中，如何使用 Kafka 将微服务之间的耦合降到最低，同时能让整个系统在保证高可用的前提下做到高可扩展。

微服务架构界的“网红”来了——崛起的 Kafka

Kafka 全面解析

Kafka 数据可靠性深度解读

Kafka 作为一个商业级消息中间件，消息可靠性的重要性可想而知。如何确保消息的精确传输？如何确保消息的准确存储？如何确保消息的正确消费？这些都是需要考虑的问题。

唯品会消息中间件团队首先从 Kafka 的架构着手，解释了 Kafka 的基本原理，然后通过对 kakfa 的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析，最后通过 benchmark 来增强对 Kafka 高可靠性的认知。

kafka 数据可靠性深度解读

Kafka Stream 设计详解

本文介绍了 Kafka Stream 的背景，如 Kafka Stream 是什么，什么是流式计算，以及为什么要有 Kafka Stream。接着介绍了 Kafka Stream 的整体架构、并行模型、状态存储以及主要的两种数据集 KStream 和 KTable。然后分析了 Kafka Stream 如何解决流式系统中的关键问题，如时间定义、窗口操作、Join 操作、聚合操作，以及如何处理乱序和提供容错能力。最后结合示例讲解了如何使用 Kafka Stream。

流式计算新贵 Kafka Stream 设计详解

Kafka 不只是个消息系统

Confluent 联合创始人兼 CEO Jay Kreps 发表了一篇博文，指出了 Kafka 的真正定位——它不只是个消息系统，它还是个存储系统，而它的终极目标是要让流式处理成为现代企业的主流开发范式。

人们更多的是把 Kafka 当成了消息队列系统。消息队列有一些不成文的规则，比如“不要在消息队列里保存消息”。传统的消息系统在设计上存在很多不足。从根本上讲，任何一个异步消息系统都会保存消息，只是时间很短，有时候只有几秒钟，直到消息被消费为止。

实际上，Kafka 并非传统意义上的消息队列，它与 RabbitMQ 等消息系统并不一样。它更像是一个分布式的文件系统或数据库。Kafka 与传统消息系统之间有三个关键区别。

• Kafka 持久化日志，这些日志可以被重复读取和无限期保留

• Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性

• Kafka 支持实时的流式处理

以上三点足以将 Kafka 与传统的消息队列区别开，我们甚至可以把它看成是流式处理平台。因此，在 Kafka 里存储数据并不是什么疯狂事，甚至可以说 Kafka 本来就是设计用来存储数据的。数据经过校验后被持久化在磁盘上，并通过复制副本提升容错能力。再多的数据都不会拖慢 Kafka，在生产环境中，有些 Kafka 集群甚至已经保存超过 1 TB 的数据。

Kafka 不只是个消息系统

在本次正式版本发布之前，Confluent 在 8 月份的 Kafka Summit 大会上宣布开源用于 Kafka 的流数据 SQL 引擎，而 LinkedIn 也开源了 Kafka 服务器集群的自动化运维工具 Cruse Control。

重磅开源 KSQL：用于 Apache Kafka 的流数据 SQL 引擎

开源 Cruise Control：LinkedIn 1800 台 Kafka 服务器集群的自动化运维利器

Kafka 实战指南

Kafka 凭借着自身的优势，越来越受到互联网企业的青睐。AI 前线集结了纽约时报、Uber、LinkedIn 等公司在实战中应用 Kafka 的技术干货，希望能够帮助大家在公司实际业务中高效落地 Kafka。

纽约时报 Kafka 架构实战

纽约时报有很多内容生成系统，我们使用第三方数据来编写故事。另外，我们有 161 年的新闻行业积累和 21 年的在线内容发布经验，所以大量的在线内容需要被搜索到，并提供给不同的服务和应用使用。

另一方面，有很多服务和应用需要访问到这些内容——搜索引擎、个性化定制服务、新闻种子生成器，以及其他各种前端应用，如网站和移动应用。一旦有新内容发布，就要在很短的时间内让这些服务访问到，而且不能有数据丢失——毕竟这些内容都是有价值的新闻。

这篇文章将详细介绍纽约时报是如何基于 Apache Kafka 解决上述问题的。

纽约时报 Kafka 架构实战

Linkedln 的流处理生态和 Kafka“危机故障”

Apache Kafka 在 LinkedIn 是作为各种数据管道和异步消息的后端被使用的。除了 LinkedIn，Netflix 和 Microsoft 也是 Kafka 的重量级使用者（Four Comma Club，每天万亿级别的消息量）。

随着 Kafka 的使用率持续地快速增长，有一些重大问题渐渐浮现出来，所以 LinkedIn 围绕 Kafka 开发了一个完整的生态系统。本文总结了 LinkedIn 的一些解决方案，希望能对正在使用 Kafka 的人有一些帮助。

涨姿势：你用 Kafka 吗？看看 LinkedIn 的流处理生态

虽然 Kafka 有着极其稳定的架构，但是在每天万亿级别消息量的大规模下也会偶尔出现有趣的 bug。本文深度分析了过去几年在 LinkedIn 所遭遇的重大“危机故障”。在这里阐述 Kafka 的“重大”bug 产生的根本原因（多种 bug、不正常的客户端行为和监控不当多种因素相互作用导致的）是“后见之明”（有点像“马后炮”的意思），但分享出来可以给广大同仁以借鉴。

本文将讲述如何探测、研究和修复这些问题，并总结出 Kafka 的一些特色以供将来消除或者减缓类似的 bug。

剖析 Linkedln 遭遇的 Kafka“危机故障”

Uber 如何对 Kafka 进行端到端审计

随着 Uber 业务规模不断增长，系统也在持续不断地产生更多的事件、服务间的消息和日志。这些数据在得到处理之前需要经过 Kafka。那么 Uber 的平台是如何实时地对这些数据进行审计的呢？

为了监控 Kafka 数据管道的健康状况并对流经 Kafka 的每个消息进行审计，Uber 完全依赖于审计系统 Chaperone，并且已经其开源。Chaperone 自 2016 年 1 月成为 Uber 的跨数据中心基础设施以来，每天处理万亿的消息量。本文会介绍它的工作原理，并说明 Uber 为什么会构建 Chaperone。

开源“Chaperone”：Uber 是如何对 Kafka 进行端到端审计的

---

今日荐文

点击下方图片即可阅读

Google Brain 工程师演讲实录：TensorFlow 与深度学习

---

---