你谈见解我送书：你所不了解的 Kafka | 感恩节福利

感恩节开源中国联合人民邮电出版社异步社区给粉丝送福利啦！！本次干货：《 Kafka 入门与实践》技术书籍。只要试读第一章内容《 Kafka入门与实践 》，11 月 27 日前在评论区写下你的见解，我们将在评论用户中抽出 5 位幸运用户送出精美图书一本！

本书以Kafka 0.10.1.1版本以基础，对Kafka的基本组件的实现细节及其基本应用进行了详细介绍，同时，通过对Kafka与当前大数据主流框架整合应用案例的讲解，进一步展现了Kafka在实际业务中的作用和地位。本书共10章，按照从抽象到具体、从点到线再到面的学习思维模式，由浅入深，理论与实践相结合，对Kafka进行了分析讲解。 

Kafka是一个高吞吐量、分布式的发布—订阅消息系统。据Kafka官方网站介绍，当前的Kafka已经定位为一个分布式流式处理平台，它最初由LinkedIn公司开发，后来成为Apache项目的一部分。Kafka核心模块使用Scala语言开发，支持多语言客户端，它以可水平扩展和具有高吞吐量等特性而被广泛使用。目前越来越多的开源分布式处理系统（如Flume、Apache Storm、Spark、Flink等）支持与Kafka集成，本书第8章至第10章将通过具体案例详细介绍Kafka与当前一些流行的分布式处理系统的集成应用。接下来我们将对Kafka相关知识做进一步深入介绍。

1.1 Kafka 背景

随着信息技术的快速发展及互联网用户规模的急剧增长，计算机所存储的信息量正呈爆炸式增长，目前数据量已进入大规模和超大规模的海量数据时代，如何高效地存储、分析、处理和挖掘海量数据已成为技术研究领域的热点和难点问题。当前出现的云存储、分布式存储系统、NoSQL数据库及列存储等前沿技术在海量数据的驱使下，正日新月异地向前发展，采用这些技术来处理大数据成为一种发展趋势。而如何采集和运营管理、分析这些数据也是大数据处理中一个至关重要的组成环节，这就需要相应的基础设施对其提供支持。针对这个需求，当前业界已有很多开源的消息系统应运而生，本书介绍的Kafka就是当前流行的一款非常优秀的消息系统。

Kafka 是一款开源的、轻量级的、分布式、可分区和具有复制备份的（Replicated）、基于ZooKeeper 协调管理的分布式流平台的功能强大的消息系统。与传统的消息系统相比，Kafka能够很好地处理活跃的流数据，使得数据在各个子系统中高性能、低延迟地不停流转。

据Kafka官方网站介绍，Kafka定位就是一个分布式流处理平台。在官方看来，作为一个流式处理平台，必须具备以下3个关键特性。

• 能够允许发布和订阅流数据。从这个角度来讲，平台更像一个消息队列或者企业级的消息系统。

• 存储流数据时提供相应的容错机制。

• 当流数据到达时能够被及时处理。

Kafka 能够很好满足以上3个特性，通过Kafka能够很好地建立实时流式数据通道，由该通道可靠地获取系统或应用程序的数据，也可以通过Kafka方便地构建实时流数据应用来转换或是对流式数据进行响应处理。特别是在0.10版本之后，Kafka推出了Kafka Streams，这让Kafka对流数据处理变得更加方便。

Kafka已发布多个版本。截止到编写本书时，Kafka的最新版本为0.10.1.1，因此本书内容都是基于该版本进行讲解。

1.2　Kafka基本结构

通过前面对Kafka背景知识的简短介绍，我们对Kafka是什么有了初步的了解，本节我们将进一步介绍Kafka作为消息系统的基本结构。我们知道，作为一个消息系统，其基本结构中至少要有产生消息的组件（消息生产者，Producer）以及消费消息的组件（消费者，Consumer）。虽然消费者并不是必需的，但离开了消费者构建一个消息系统终究是毫无意义的。Kafka消息系统最基本的体系结构如图1-1所示。

图1-1　Kafka消息系统最基本的体系结构

生产者负责生产消息，将消息写入Kafka集群；消费者从Kafka集群中拉取消息。至于生产者如何将生产的消息写入 Kafka，消费者如何从 Kafka 集群消费消息，Kafka 如何存储消息，Kafka 集群如何管理调度，如何进行消息负载均衡，以及各组件间如何进行通信等诸多问题，我们将在后续章节进行详细阐述，在本节我们只需对Kafka基本结构轮廓有个清晰认识即可。随着对Kafka相关知识的深入学习，我们将逐步对Kafka的结构图进行完善。

1.3　Kafka基本概念

在对Kafka基本体系结构有了一定了解后，本节我们对Kafka的基本概念进行详细阐述。

1．主题

Kafka将一组消息抽象归纳为一个主题（Topic），也就是说，一个主题就是对消息的一个分类。生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费。

2．消息

消息是Kafka通信的基本单位，由一个固定长度的消息头和一个可变长度的消息体构成。在老版本中，每一条消息称为Message；在由Java重新实现的客户端中，每一条消息称为Record。

3．分区和副本

Kafka将一组消息归纳为一个主题，而每个主题又被分成一个或多个分区（Partition）。每个分区由一系列有序、不可变的消息组成，是一个有序队列。

每个分区在物理上对应为一个文件夹，分区的命名规则为主题名称后接“—”连接符，之后再接分区编号，分区编号从0开始，编号最大值为分区的总数减1。

每个分区又有一至多个副本（Replica），分区的副本分布在集群的不同代理上，以提高可用性。从存储角度上分析，分区的每个副本在逻辑上抽象为一个日志（Log）对象，即分区的副本与日志对象是一一对应的。每个主题对应的分区数可以在Kafka启动时所加载的配置文件中配置，也可以在创建主题时指定。当然，客户端还可以在主题创建后修改主题的分区数。

分区使得Kafka在并发处理上变得更加容易，理论上来说，分区数越多吞吐量越高，但这要根据集群实际环境及业务场景而定。同时，分区也是Kafka保证消息被顺序消费以及对消息进行负载均衡的基础。

Kafka只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。每条消息被追加到相应的分区中，是顺序写磁盘，因此效率非常高，这是Kafka高吞吐率的一个重要保证。同时与传统消息系统不同的是，Kafka并不会立即删除已被消费的消息，由于磁盘的限制消息也不会一直被存储（事实上这也是没有必要的），因此Kafka提供两种删除老数据的策略，一是基于消息已存储的时间长度，二是基于分区的大小。这两种策略都能通过配置文件进行配置，在这里不展开探讨，在3.5.4节将详细介绍。

4．Leader副本和Follower副本

由于Kafka副本的存在，就需要保证一个分区的多个副本之间数据的一致性，Kafka会选择该分区的一个副本作为Leader副本，而该分区其他副本即为Follower副本，只有Leader副本才负责处理客户端读/写请求，Follower副本从Leader副本同步数据。

如果没有Leader副本，那就需要所有的副本都同时负责读/写请求处理，同时还得保证这些副本之间数据的一致性，假设有n个副本则需要有n×n条通路来同步数据，这样数据的一致性和有序性就很难保证。

引入Leader副本后客户端只需与Leader副本进行交互，这样数据一致性及顺序性就有了保证。Follower副本从Leader副本同步消息，对于n个副本只需n−1条通路即可，这样就使得系统更加简单而高效。副本Follower与Leader的角色并不是固定不变的，如果Leader失效，通过相应的选举算法将从其他Follower副本中选出新的Leader副本。

5．偏移量

任何发布到分区的消息会被直接追加到日志文件（分区目录下以“.log”为文件名后缀的数据文件）的尾部，而每条消息在日志文件中的位置都会对应一个按序递增的偏移量。

偏移量是一个分区下严格有序的逻辑值，它并不表示消息在磁盘上的物理位置。由于Kafka几乎不允许对消息进行随机读写，因此Kafka并没有提供额外索引机制到存储偏移量，也就是说并不会给偏移量再提供索引。消费者可以通过控制消息偏移量来对消息进行消费，如消费者可以指定消费的起始偏移量。

为了保证消息被顺序消费，消费者已消费的消息对应的偏移量也需要保存。

需要说明的是，消费者对消息偏移量的操作并不会影响消息本身的偏移量。旧版消费者将消费偏移量保存到ZooKeeper当中，而新版消费者是将消费偏移量保存到Kafka内部一个主题当中。当然，消费者也可以自己在外部系统保存消费偏移量，而无需保存到Kafka中。

6．日志段

一个日志又被划分为多个日志段（LogSegment），日志段是Kafka日志对象分片的最小单位。与日志对象一样，日志段也是一个逻辑概念，一个日志段对应磁盘上一个具体日志文件和两个索引文件。

日志文件是以“.log”为文件名后缀的数据文件，用于保存消息实际数据。两个索引文件分别以“.index”和“.timeindex”作为文件名后缀，分别表示消息偏移量索引文件和消息时间戳索引文件。

7．代理

在Kafka基本体系结构中我们提到了Kafka集群。

Kafka集群就是由一个或多个Kafka实例构成，我们将每一个Kafka实例称为代理（Broker），通常也称代理为Kafka服务器（KafkaServer）。

在生产环境中Kafka集群一般包括一台或多台服务器，我们可以在一台服务器上配置一个或多个代理。每一个代理都有唯一的标识id，这个id是一个非负整数。在一个Kafka集群中，每增加一个代理就需要为这个代理配置一个与该集群中其他代理不同的id，id值可以选择任意非负整数即可，只要保证它在整个Kafka集群中唯一，这个id就是代理的名字，也就是在启动代理时配置的broker.id对应的值，因此在本书中有时我们也称为brokerId。

由于给每个代理分配了不同的brokerId，这样对代理进行迁移就变得更方便，从而对消费者来说是透明的，不会影响消费者对消息的消费。代理有很多个参数配置，由于在本节只是对其概念进行阐述，因此不做深入展开，对于代理相关配置将穿插在本书具体组件实现原理、流程分析及相关实战操作章节进行介绍。

8．生产者

生产者（Producer）负责将消息发送给代理，也就是向Kafka代理发送消息的客户端。

9．消费者和消费组

消费者（Comsumer）以拉取（pull）方式拉取数据，它是消费的客户端。在Kafka中每一个消费者都属于一个特定消费组（ConsumerGroup），我们可以为每个消费者指定一个消费组，以groupId代表消费组名称，通过group.id配置设置。

如果不指定消费组，则该消费者属于默认消费组test-consumer-group。同时，每个消费者也有一个全局唯一的id，通过配置项client.id指定，如果客户端没有指定消费者的id，Kafka会自动为该消费者生成一个全局唯一的id，格式为${groupId}-${hostName}-${timestamp}-${UUID前8位字符}。

同一个主题的一条消息只能被同一个消费组下某一个消费者消费，但不同消费组的消费者可同时消费该消息。消费组是Kafka用来实现对一个主题消息进行广播和单播的手段，实现消息广播只需指定各消费者均属于不同的消费组，消息单播则只需让各消费者属于同一个消费组。

10．ISR

Kafka在ZooKeeper中动态维护了一个ISR（In-sync Replica），即保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower副本宕机（本书用宕机来特指某个代理失效的情景，包括但不限于代理被关闭，如代理被人为关闭或是发生物理故障、心跳检测过期、网络延迟、进程崩溃等）或是落后太多，则该Follower副本节点将从ISR列表中移除。

11．ZooKeeper

这里我们并不打算介绍ZooKeeper的相关知识，只是简要介绍ZooKeeper在Kafka中的作用。Kafka利用ZooKeeper保存相应元数据信息，Kafka元数据信息包括如代理节点信息、Kafka集群信息、旧版消费者信息及其消费偏移量信息、主题信息、分区状态信息、分区副本分配方案信息、动态配置信息等。

Kafka在启动或运行过程当中会在ZooKeeper上创建相应节点来保存元数据信息，Kafka通过监听机制在这些节点注册相应监听器来监听节点元数据的变化，从而由ZooKeeper负责管理维护Kafka集群，同时通过ZooKeeper我们能够很方便地对Kafka集群进行水平扩展及数据迁移。

通过以上Kafka基本概念的介绍，我们可以对Kafka基本结构图进行完善，如图1-2所示。

图1-2　Kafka的集群

本书导读

本书在结构编排上，先介绍Kafka基础知识，接着介绍Kafka应用环境搭建，然后对Kafka核心组件实现原理进行简要讲解。在核心组件原理讲解之后，又将相应组件应用串起来分析Kafka核心流程，之后从Kafka基本脚本操作实战开始，结合Kafka在实际工作中应用案例详细介绍Kafka与当前主流大数据处理框架的应用。同时，将Kafka Streams独立成一章进行详细介绍，基本上覆盖了Kafka Streams的核心及重要知识的讲解。

为了编写和讲解方便，本书有以下几点约定说明。

（1）本书所讲Kafka版本为0.10.1.1，书中提及的当前版本Kafka均指这一版本。

（2）在Kafka基本组件实现原理讲解时，为了指明方法所属的对象，本书简单地以“类名.方法名()”的形式说明，这并不表示对类静态方法的调用。同时，鉴于篇幅考虑也省去了方法参数列表，但不代表该方法无参数。

（3）读者在阅读本书时经常会看到“${属性字段}”表达式，本书以此表示该属性字段对应的值。

本文摘自：《 Kafka入门与实践 》

试读：http://www.epubit.com.cn/book/details/4851 

购书：https://item.jd.com/12220149.html 

想要了解更多有关 Kotlin 程序开发的知识吗？赶紧在评论区写下你的见解吧，可能获奖的就是你哦！

推荐阅读

点击“阅读原文”查看更多精彩内容