每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。如何移动数据，几乎变得与数据本身一样重要。如果你是架构师、产品工程师，同时也是Apache Kafka新手，那么这本实践指南将会帮助你成为流式平台上处理实时数据的专家。

　　本书由出身于LinkedIn的Kafka核心作者和一线技术人员共同执笔，详细介绍了如何部署Kafka集群、开发可靠的基于事件驱动的微服务，以及基于Kafka平台构建可伸缩的流式应用程序。通过详尽示例，你将会了解到Kafka的设计原则、可靠性保证、关键API，以及复制协议、控制器和存储层等架构细节。

　　● 了解发布和订阅消息模型以及该模型如何被应用在大数据生态系统中
　　● 学习使用Kafka生产者和消费者来生成消息和读取消息
　　● 了解Kafka保证可靠性数据传递的模式和场景需求
　　● 使用Kafka构建数据管道和应用程序的实践
　　● 在生产环境中管理Kafka，包括监控、调优和维护
　　● 了解Kafka的关键度量指标
　　● 探索Kafka如何成为流式处理利器

特别说明：购买此电子书，暂无视频，敬请谅解。

　　本书是关于Kafka的全面教程，主要内容包括：Kafka相对于其他消息队列系统的优点，主要是它如何匹配大数据平台开发；详解Kafka内部设计；用Kafka构建应用的实践；理解在生产中部署Kafka的方式；如何确保Kafka集群的安全。
　　本书适合Java开发人员、大数据平台开发人员以及对分布式系统感兴趣的读者阅读。

　　Neha Narkhede， Confluent联合创始人、CTO，曾在LinkedIn主导基于Kafka和Apache Samza构建流式基础设施，是Kafka作者之一。
　　Gwen Shapira， Confluent系统架构师，帮助客户构建基于Kafka的系统，在可伸缩数据架构方面拥有十余年经验；曾任Cloudera公司解决方案架构师。另著有《Hadoop应用架构》。
　　Todd Palino， LinkedIn主任级SRE，负责部署管理大型的Kafka、Zookeeper和Samza集群。
　　【译者简介】
　　薛命灯，毕业于厦门大学软件学院，十余年软件开发和架构经验，InfoQ社区编辑。译有《硅谷革命》《生产微服务》等书。微信公众号CodeDeep。

O'Reilly Media，Inc．介绍
业界评论
序
前言
第1章　初识 Kafka
1.1　发布与订阅消息系统
1.2　Kafka登场
1.3　为什么选择Kafka
1.4　数据生态系统
1.5　起源故事
1.6　开始Kafka之旅
第2章　安装 Kafka
2.1　要事先行
2.2　安装Kafka Broker
2.3　broker配置
2.4　硬件的选择
2.5　云端的Kafka
2.6　Kafka集群
2.7　生产环境的注意事项
2.8　总结
第3章　Kafka 生产者——向 Kafka 写入数据
3.1　生产者概览
3.2　创建Kafka生产者
3.3　发送消息到Kafka
3.4　生产者的配置
3.5　序列化器
3.6　分区
3.7　旧版的生产者API
3.8　总结
第4章　Kafka 消费者——从 Kafka 读取数据
4.1　KafkaConsumer概念
4.2　创建Kafka消费者
4.3　订阅主题
4.4　轮询
4.5　消费者的配置
4.6　提交和偏移量
4.7　再均衡监听器
4.8　从特定偏移量处开始处理记录
4.9　如何退出
4.10　反序列化器
4.11　独立消费者——为什么以及怎样使用没有群组的消费者
4.12　旧版的消费者API
4.13　总结
第5章　深入 Kafka
5.1　集群成员关系
5.2　控制器
5.3　复制
5.4　处理请求
5.5　物理存储
5.6　总结
第6章　可靠的数据传递
6.1　可靠性保证
6.2　复制
6.3　broker配置
6.4　在可靠的系统里使用生产者
6.5　在可靠的系统里使用消费者
6.6　验证系统可靠性
6.7　总结
第7章　构建数据管道
7.1　构建数据管道时需要考虑的问题
7.2　如何在Connect API和客户端API之间作出选择
7.3　Kafka Connect
7.4　Connect之外的选择
7.5　总结
第8章　跨集群数据镜像
8.1　跨集群镜像的使用场景
8.2　多集群架构
8.3　Kafka的MirrorMaker
8.4　其他跨集群镜像方案
8.5　总结
第9章　管理 Kafka
9.1　主题操作
9.2　消费者群组
9.3　动态配置变更
9.4　分区管理
9.5　消费和生产
9.6　客户端ACL
9.7　不安全的操作
9.8　总结
第10章　监控 Kafka
10.1　度量指标基础
10.2　broker的度量指标
10.3　客户端监控
10.4　延时监控
10.5　端到端监控
10.6　总结
第11章　流式处理
11.1　什么是流式处理
11.2　流式处理的一些概念
11.3　流式处理的设计模式
11.4　Streams示例
11.5　Kafka Streams的架构概览
11.6　流式处理使用场景
11.7　如何选择流式处理框架
11.8　总结
附录A　在其他操作系统上安装 Kafka
A.1　在Windows上安装Kafka
A.2　在MacOS上安装Kafka
作者介绍
介绍

　　给予一个技术书籍作者最好的赞赏莫过于这句话——“如果在一开始接触这门技术时能看到这本书就好了”。在开始写这本书的时候，我们就是以这句话作为写作目标。我们开发Kafka，在生产环境运行 Kafka，帮助很多公司构建基于 Kafka 的系统，帮助他们管理数据管道，积累了很多经验，但也困惑：“应该把哪些东西分享给 Kafka 新用户，让他们从新手变成专家？”这本书就是我们日常工作最好的写照：运行 Kafka 并帮助其他人更好地使用 Kafka。
　　我们相信，书中提供的这些内容能够帮助 Kafka 用户在生产环境运行 Kafka 以及基于Kafka 构建健壮的高性能应用程序。我们列举了一些非常流行的应用场景：用于事件驱动微服务系统的消息总线、流式应用和大规模数据管道。这本书通俗易懂，能够帮助每一个Kafka 用户在任意的架构或应用场景里使用好 Kafka。书中介绍了如何安装和配置 Kafka、如何使用 Kafka API、Kafka 的设计原则和可靠性保证，以及 Kafka 的一些架构细节，如复制协议、控制器和存储层。我们相信，Kafka 的设计原理和内部架构不仅会成为分布式系统构建者的兴趣所在，对于那些在生产环境部署 Kafka 或使用 Kafka 构建应用程序的人来说也是非常有用的。越是了解 Kafka，就越是能够更好地作出权衡。
　　在软件工程里，条条道路通罗马，每一个问题都有多种解决方案。Kafka 为专家级别的用户提供了巨大的灵活性，而新手则需要克服陡峭的学习曲线才能成为专家。Kafka 通常会告诉你如何使用某个功能特性，但不会告诉你为什么要用它或者为什么不该用它。我们会尽可能地解释我们的设计决策和权衡背后的缘由，以及用户在哪些情况下应该或不应该使用 Kafka 提供的特性。
　　读者对象
　　这本书是为使用 Kafka API 开发应用程序的工程师和在生产环境安装、配置、调优、监控Kafka 的运维工程师（也可以叫作 SRE、运维人员或系统管理员）而写的。我们也考虑到了数据架构师和数据工程师，他们负责设计和构建整个组织的数据基础架构。某些章节（特别是第 3 章、第 4 章和第 11 章）主要面向 Java 开发人员，并假设读者已经熟悉基本的Java 语言编程，比如异常处理和并发编程。其他章节（特别是第 2 章、第 8 章、第 9 章和第 10 章）则假设读者在 Linux 的运行、存储和网络配置方面有一定的经验。本书的其余部分则讨论了一般性的软件架构，不要求读者具备特定的知识。
　　另一类可能对本书感兴趣的人是那些经理或架构师，他们不直接使用 Kafka，但会与使用Kafka 的工程师打交道。他们有必要了解 Kafka 所能提供的保证机制，以及他们的同事在构建基于 Kafka 的系统时所作出的权衡。这本书可以成为企业管理人员的利器，确保他们的工程师在 Kafka 方面训练有素，让他们的团队了解他们本该知道的知识。
　　排版约定
　　本书使用了下列排版约定。
　　黑体
　　表示新术语或重点强调的内容。
　　等宽字体（constant width）
　　表示程序片段，以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。
　　加粗等宽字体（constant width bold）
　　表示应该由用户输入的命令或其他文本。
　　等宽斜体（constant width italic）
　　表示应该由用户输入的值或根据上下文确定的值替换的文本。
　　使用代码示例
　　本书是要帮你完成工作的。一般来说，如果本书提供了示例代码，你可以把它用在你的程序或文档中。除非你使用了很大一部分代码，否则无需联系我们获得许可。比如，用本书的几个代码片段写一个程序就无需获得许可，销售或分发 O’Reilly 图书的示例光盘则需要获得许可；引用本书中的示例代码回答问题无需获得许可，将书中大量的代码放到你的产品文档中则需要获得许可。
　　我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和 ISBN。例如“Kafka 权威指南，作者 Neha Narkhede、Gwen Shapira 和 Todd Palino（O’Reilly），版权归 Neha Narkhede、Gwen Shapira 和 Todd Palino 所有，978-1-4919-3616-0”。
　　如果你觉得自己对示例代码的用法超出了上述许可的范围，欢迎你通过 permissions@ oreilly.com 与我们联系。
　　O’Reilly Safari
　　Safari（原来叫 Safari Books Online）是面向企业、政府、教育从业者和个人的会员制培训和参考咨询平台。
　　些资源来自 250 多家出版机构，其中包括 O’Reilly Media、Harvard Business Review、 Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、 Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley＆Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones＆Bartlett 和 Course Technology。
　　更多信息，请访问 //oreilly.com/safari。
　　联系我们
　　请把对本书的评价和问题发给出版社。
　　美国：
　　O’Reilly Media, Inc.
　　1005 Gravenstein Highway North Sebastopol, CA 95472
　　中国：
　　北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室（100035）奥莱利技术咨询（北京）有限公司
　　O’Reilly 的每一本书都有专属网页，你可以在那儿找到本书的相关信息，包括勘误表、示例代码以及其他信息。本书的网站地址是 //oreil.ly/2tVmYjk。
　　对于本书的评论和技术性问题，请发送电子邮件到：bookquestions@oreilly.com
　　要了解更多 O’Reilly 图书、培训课程、会议和新闻的信息，请访问以下网站：
　　//www.oreilly.com
　　我们在 Facebook 的地址如下：//facebook.com/oreilly
　　请关注我们的 Twitter 动态：//twitter.com/oreillymedia
　　我们的 YouTube 视频地址如下：//www.youtube.com/oreillymedia
　　致谢
　　我们想感谢众多为 Kafka 和它的生态系统做出贡献的人。如果没有他们艰辛的工作，就不会有这本书的问世。特别感谢 Jay Kreps、Neha Narkhede 和 Jun Rao，以及他们在 LinkedIn的同事和领导，他们创造了 Kafka，并把它捐献给了 Apache 软件基金会。
　　很多人在早前为本书提供了很多有价值的反馈，我们非常感激他们为此付出的时间，也很钦佩他们的专业能力，这些人包括：Apurva Mehta、Arseniy Tashoyan、Dylan Scott、 Ewen Cheslack-Postava、Grant Henke、Ismael Juma、James Cheng、Jason Gustafson、Jeff Holoman、Joel Koshy、Jonathan Seidman、Matthias Sax、Michael Noll、Paolo Castagna。我们还想感谢众多在网站上留下评论和反馈的读者。
　　很多审稿人提供了有价值的意见，极大改进了本书的质量。书中的遗留错误理应由我们作者负责。
　　我们要感谢 O’Reilly 编辑 Shannon Cutt 的鼓励、耐心和深谋远虑。对于一个作者来说，与O’Reilly 一起合作是一段非凡的经历——他们所提供的支持，从工具到签名售书，都是无可匹敌的。我们感谢每一个参与本书相关工作的人，很感激他们愿意与我们一起工作。
　　另外，我们也想感谢我们的领导和同事，感谢他们在我们写作这本书的过程中给予的帮助和鼓励。
　　Gwen 要感谢她的丈夫 Omer Shapira，在她写书的几个月时间里，他一直给予她支持和耐心。还有她的父亲 Lior Shapira，让她学会了如何在困难面前不轻言放弃，尽管这种生活哲学总是让她麻烦不断。
　　Todd 要感谢他的妻子 Marcy 和女儿 Bella 及 Kaylee，她们一直在背后默默地支持他。因为有了她们的支持，他才有更多的时间写作，才能厘清思路，坚持到最后。

　　数据为企业的发展提供动力。我们从数据中获取信息，对它们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。例如，我们每天在 Amazon 网站上浏览感兴趣的商品，浏览信息被转化成商品推荐，并在稍后展示给我们。
　　这个过程完成得越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就越能专注于核心业务。这就是为什么在一个以数据为驱动的企业里，数据管道会成为关键性组件。如何移动数据，几乎变得与数据本身一样重要。
　　每一次科学家们发生分歧，都是因为掌握的数据不够充分。所以我们可以先就获取哪一类数据达成一致。只要获取了数据，问题也就迎刃而解了。要么我是对的，要么你是对的，要么我们都是错的。然后我们继续研究。
　　——Neil deGrasse Tyson
　　1.1　发布与订阅消息系统
　　在正式讨论 Apache Kafka（以下简称 Kafka）之前，先来了解发布与订阅消息系统的概念，并认识这个系统的重要性。数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。发布与订阅系统一般会有一个 broker，也就是发布消息的中心点。
　　1.1.1　如何开始
　　发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通道开始的。例如，你的应用程序需要往别处发送监控信息，可以直接在你的应用程序和另一个可以在仪表盘上显示度量指标的应用程序之间建立连接，然后通过这个连接推送度量指标，如图 1-1 所示。
　　这是刚接触监控系统时简单问题的应对方案。过了不久，你需要分析更长时间片段的度量指标，而此时的仪表盘程序满足不了需求，于是，你启动了一个新的服务来接收度量指标。该服务把度量指标保存起来，然后进行分析。与此同时，你修改了原来的应用程序，把度量指标同时发送到两个仪表盘系统上。现在，你又多了 3 个可以生成度量指标的应用程序，它们都与这两个服务直接相连。而你的同事认为最好可以对这些服务进行轮询以便获得告警功能，于是你为每一个应用程序增加了一个服务器，用于提供度量指标。再过一阵子，有更多的应用程序出于各自的目的，都从这些服务器获取度量指标。这时的架构看起来就像图 1-2 所示的那样，节点间的连接一团糟。
　　这时，技术债务开始凸显出来，于是你决定偿还掉一些。你创建了一个独立的应用程序，用于接收来自其他应用程序的度量指标，并为其他系统提供了一个查询服务器。这样，之前架构的复杂度被降低到图 1-3 所示的那样。那么恭喜你，你已经创建了一个基于发布与订阅的消息系统。
　　1.1.2　独立的队列系统
　　在你跟度量指标打得不可开交的时候，你的一个同事也正在跟日志消息奋战。还有另一个同事正在跟踪网站用户的行为，为负责机器学习开发的同事提供信息，同时为管理团队生成报告。你和同事们使用相同的方式创建这些系统，解耦信息的发布者和订阅者。图 1-4 所示的架构包含了 3 个独立的发布与订阅系统。
　　这种方式比直接使用点对点的连接（图 1-2）要好得多，但这里有太多重复的地方。你的公司因此要为数据队列维护多个系统，每个系统又有各自的缺陷和不足。而且，接下来可能会有更多的场景需要用到消息系统。此时，你真正需要的是一个单一的集中式系统，它可以用来发布通用类型的数据，其规模可以随着公司业务的增长而增长。
　　1.2　Kafka登场
　　Kafka 就是为了解决上述问题而设计的一款基于发布与订阅的消息系统。它一般被称为“分布式提交日志”或者“分布式流平台”。文件系统或数据库提交日志用来提供所有事务的持久记录，通过重放这些日志可以重建系统的状态。同样地，Kafka 的数据是按照一定顺序持久化保存的，可以按需读取。此外，Kafka 的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。