kafka-最新实战

Kafka 由于高吞吐量、可持久化、分布式、支持流数据处理等特性而被广泛应用。但当前关于Kafka原理及应用的相关资料较少，在我打算编写本文时，还没有见到中文版本的Kafka相关书籍，对于初学者甚至是一些中高级应用者来说学习成本还是比较高的，因此我打算在对Kafka进行深入而系统的研究基础上，结合自己在工作中的实践经验，编写一本介绍Kafka原理及其基本应用的书籍，以帮助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的集群结构

1.4　Kafka设计概述

1.4.1　Kafka设计动机

Kafka的设计初衷是使Kafka能够成为统一、实时处理大规模数据的平台。为了达到这个目标，Kafka必须支持以下几个应用场景。

（1）具有高吞吐量来支持诸如实时的日志集这样的大规模事件流。

（2）能够很好地处理大量积压的数据，以便能够周期性地加载离线数据进行处理。

（3）能够低延迟地处理传统消息应用场景。

（4）能够支持分区、分布式，实时地处理消息，同时具有容错保障机制。

满足以上功能的Kafka与传统的消息系统相比更像是一个数据库日志系统。了解了Kafka的设计动机之后，在下一节我们将看看Kafka发展至今已具有哪些特性。

1.4.2　Kafka特性

上一节对Kafka的设计动机进行了介绍。随着Kafka的不断更新发展，当前版本的Kafka又增加了一些新特性，下面就来逐个介绍Kafka的这些新特性。

1．消息持久化

Kafka高度依赖于文件系统来存储和缓存消息。说到文件系统，大家普遍认为磁盘读写慢，依赖于文件系统进行存储和缓存消息势必在性能上会大打折扣，其实文件系统存储速度快慢一定程度上也取决于我们对磁盘的用法。据Kafka官方网站介绍：6块7200r/min SATA RAID-5阵列的磁盘线性写的速度为600 MB/s，而随机写的速度为100KB/s，线性写的速度约是随机写的6000多倍。由此看来磁盘的快慢取决于我们是如何去应用磁盘。加之现代的操作系统提供了预读（read-ahead）和延迟写（write-behind）技术，使得磁盘的写速度并不是大家想象的那么慢。同时，由于Kafka是基于JVM（Java Virtual Machine）的，而Java对象内存消耗非常高，且随着Java对象的增加JVM的垃圾回收也越来越频繁和繁琐，这些都加大了内存的消耗。鉴于以上因素，使用文件系统和依赖于页缓存（page cache）的存储比维护一个内存的存储或是应用其他结构来存储消息更有优势，因此Kafka选择以文件系统来存储数据。

消息系统数据持久化一般采用为每个消费者队列提供一个 B 树或其他通用的随机访问数据结构来维护消息的元数据，B树操作的时间复杂度为O(log n)，O(log n)的时间复杂度可以看成是一个常量时间，而且B树可以支持各种各样的事务性和非事务性语义消息的传递。尽管B树具有这些优点，但这并不适合磁盘操作。目前的磁盘寻道时间一般在10ms以内，对一块磁盘来说，在同一时刻只能有一个磁头来读写磁盘，这样在并发IO能力上就有问题。同时，对树结构性能的观察结果表明：其性能会随着数据的增长而线性下降。鉴于消息系统本身的作用考虑，数据的持久化队列可以建立在简单地对文件进行追加的实现方案上。因为是顺序追加，所以Kafka在设计上是采用时间复杂度O(1)的磁盘结构，它提供了常量时间的性能，即使是存储海量的信息（TB级）也如此，性能和数据的大小关系也不大，同时Kafka将数据持久化到磁盘上，这样只要磁盘空间足够大数据就可以一直追加，而不会像一般的消息系统在消息被消费后就删除掉，Kafka提供了相关配置让用户自己决定消息要保存多久，这样为消费者提供了更灵活的处理方式，因此Kafka能够在没有性能损失的情况下提供一般消息系统不具备的特性。

正是由于Kafka将消息进行持久化，使得Kafka在机器重启后，已存储的消息可继续恢复使用。同时Kafka能够很好地支持在线或离线处理、与其他存储及流处理框架的集成。

2．高吞吐量

高吞吐量是Kafka设计的主要目标，Kafka将数据写到磁盘，充分利用磁盘的顺序读写。同时，Kafka在数据写入及数据同步采用了零拷贝（zero-copy）技术，采用sendFile()函数调用，sendFile()函数是在两个文件描述符之间直接传递数据，完全在内核中操作，从而避免了内核缓冲区与用户缓冲区之间数据的拷贝，操作效率极高。Kafka还支持数据压缩及批量发送，同时Kafka将每个主题划分为多个分区，这一系列的优化及实现方法使得Kafka具有很高的吞吐量。经大多数公司对Kafka应用的验证，Kafka支持每秒数百万级别的消息。

3．扩展性

Kafka要支持对大规模数据的处理，就必须能够对集群进行扩展，分布式必须是其特性之一，这样就可以将多台廉价的PC服务器搭建成一个大规模的消息系统。Kafka依赖ZooKeeper来对集群进行协调管理，这样使得Kafka更加容易进行水平扩展，生产者、消费者和代理都为分布式，可配置多个。同时在机器扩展时无需将整个集群停机，集群能够自动感知，重新进行负责均衡及数据复制。

4．多客户端支持

Kafka核心模块用Scala语言开发，但Kafka支持不同语言开发生产者和消费者客户端应用程序。0.8.2之后的版本增加了Java版本的客户端实现，0.10之后的版本已废弃Scala语言实现的Producer及Consumer，默认使用Java版本的客户端。Kafka提供了多种开发语言的接入，如Java、Scala、C、C++、Python、Go、Erlang、Ruby、Node.js等，感兴趣的读者可以自行参考https://cwiki.apache.org/confluence/display/KAFKA/Clients。同时，Kafka支持多种连接器（Connector）的接入，也提供了Connector API供开发者调用。Kafka与当前主流的大数据框架都能很好地集成，如Flume、Hadoop、HBase、Hive、Spark、Storm等。

5．Kafka Streams

Kafka在0.10之后版本中引入Kafak Streams。Kafka Streams是一个用Java语言实现的用于流处理的jar文件，关于Kafka Streams的相关内容将在第7章中进行讲解。

6．安全机制

当前版本的Kafka支持以下几种安全措施：

• 通过SSL和SASL(Kerberos)，SASL/PLAIN验证机制支持生产者、消费者与代理连接时的身份认证；

• 支持代理与ZooKeeper连接身份验证；

• 通信时数据加密；

• 客户端读、写权限认证；

• Kafka支持与外部其他认证授权服务的集成。

7．数据备份

Kafka可以为每个主题指定副本数，对数据进行持久化备份，这可以一定程度上防止数据丢失，提高可用性。

8．轻量级

Kafka的代理是无状态的，即代理不记录消息是否被消费，消费偏移量的管理交由消费者自己或组协调器来维护。同时集群本身几乎不需要生产者和消费者的状态信息，这就使得Kafka非常轻量级，同时生产者和消费者客户端实现也非常轻量级。

9．消息压缩

Kafka支持Gzip、Snappy、LZ4这3种压缩方式，通常把多条消息放在一起组成MessageSet，然后再把MessageSet放到一条消息里面去，从而提高压缩比率进而提高吞吐量。

1.4.3　Kafka应用场景

消息系统或是说消息队列中间件是当前处理大数据一个非常重要的组件，用来解决应用解耦、异步通信、流量控制等问题，从而构建一个高效、灵活、消息同步和异步传输处理、存储转发、可伸缩和最终一致性的稳定系统。当前比较流行的消息中间件有Kafka、RocketMQ、RabbitMQ、ZeroMQ、ActiveMQ、MetaMQ、Redis等，这些消息中间件在性能及功能上各有所长。如何选择一个消息中间件取决于我们的业务场景、系统运行环境、开发及运维人员对消息中件间掌握的情况等。我认为在下面这些场景中，Kafka是一个不错的选择。

（1）消息系统。Kafka作为一款优秀的消息系统，具有高吞吐量、内置的分区、备份冗余分布式等特点，为大规模消息处理提供了一种很好的解决方案。

（2）应用监控。利用Kafka采集应用程序和服务器健康相关的指标，如CPU占用率、IO、内存、连接数、TPS、QPS等，然后将指标信息进行处理，从而构建一个具有监控仪表盘、曲线图等可视化监控系统。例如，很多公司采用Kafka与ELK（ElasticSearch、Logstash和Kibana）整合构建应用服务监控系统。

（3）网站用户行为追踪。为了更好地了解用户行为、操作习惯，改善用户体验，进而对产品升级改进，将用户操作轨迹、内容等信息发送到Kafka集群上，通过Hadoop、Spark或Strom等进行数据分析处理，生成相应的统计报告，为推荐系统推荐对象建模提供数据源，进而为每个用户进行个性化推荐。

（4）流处理。需要将已收集的流数据提供给其他流式计算框架进行处理，用Kafka收集流数据是一个不错的选择，而且当前版本的Kafka提供了Kafka Streams支持对流数据的处理。

（5）持久性日志。Kafka可以为外部系统提供一种持久性日志的分布式系统。日志可以在多个节点间进行备份，Kafka为故障节点数据恢复提供了一种重新同步的机制。同时，Kafka很方便与HDFS和Flume进行整合，这样就方便将Kafka采集的数据持久化到其他外部系统。

kafka基础最佳实战(覆盖原书第5章)

5.1　KafkaServer管理

Kafka运行依赖于ZooKeeper，在启动Kafka之前，首先要保证ZooKeeper已正常启动。在$KAFKA_HOME/bin目录下，Kafka自带了ZooKeeper操作的相应脚本，读者可以修改该目录下ZooKeeper相关脚本，然后运行。这里对ZooKeeper操作并未使用Kafka提供的脚本，而是直接执行$ZOOKEEPER_HOME/bin目录下提供的相应操作脚本及命令。Kafka提供了启动KafkaServer的执行脚本kafka-server-start.sh，而该脚本核心代码是调用kafka-run-class.sh脚本编译kafka.Kafka类，代码如下：

exec $base_dir/kafka-run-class.sh $EXTRA_ARGS kafka.Kafka "$@"

kafka-run-class.sh是Kafka自带的用来直接编译运行Kafka源码中有main方法的Scala文件。根据启动KafkaServer时调用脚本的不同，对KafkaServer启动操作分以下两小节分别进行介绍。

5.1.1　启动Kafka单个节点

Kafka提供了直接启动本地KafkaServer的执行脚本kafka-server-start.sh，该脚本在调用执行时需要传入server.properties文件路径，当然该文件名可以随意指定，在启动时KafkaServer读取并解析该文件中相关配置信息以完成KafkaServer的实例化。

1．启动脚本分析

kafka-server-start.sh脚本执行入参定义如下：

if [ $# -lt 1 ]; then

echo "USAGE: $0 [-daemon] server.properties [--override property=value]*"

exit 1

可以看到，在执行该脚本时必须指定KafkaServer用于实例化的配置文件，可选参数-daemon表示使程序以守护进程的方式后台运行。在启动时我们还可以覆盖KafkaConfig相应的默认配置，格式为：--override property=value，其中property表示待覆盖的配置项名称，value为该配置项新设置的值。

在Kafka运行时，会创建相应的日志文件以便对Kafka运行状况及异常情况进行跟踪，因此在该脚本中配置了$KAFKA_LOG4J_OPTS参数，代码如下：

if [ "x$KAFKA_LOG4J_OPTS" = "x" ]; then

export KAFKA_LOG4J_OPTS="-Dlog4j.configuration =

file:$base_dir/../config/log4j.properties"

其中$basedir为$KAFKA_HOME/bin目录，这里指定在Kafka启动时加载的是$KAFKA HOME/config/log4j.properties文件，因此若读者希望对Kafka输出日志进行调整，如开启或关闭某些运行日志输出、修改Kafka运行日志切分规则（默认是按小时进行切分）等，只需对该log4j.properties文件修改即可。

同时，该脚本还对JVM的内存HEAP大小进行了设置，代码如下：

if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then

export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"

默认堆初始化（-Xms）空间为1 GB，堆最大空间为1 GB，因此若运行Kafka的服务器内存大小不足时会导致Kafka启动失败。例如，尝试修改该脚本内存分配大小大于机器物理内存并以非-daemon方式启动Kafka时，在控制台输出以下启动失败日志：

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000003c0000000,

17179869184, 0) failed; error='Cannot allocate memory' (errno=12)

# There is insufficient memory for the Java Runtime Environment to continue.

# Native memory allocation (mmap) failed to map 17179869184 bytes for committing

reserved memory.

# An error report file with more information is saved as:

# /usr/local/software/kafka/kafka_2.11-0.10.1.1/bin/hs_err_pid19768.log

在hserr_pid19768.log文件中有相关异常信息的详细描述。由于这里设置了KAFKA_HEAP OPTS，这样就方便我们设置JVM调优的相关配置，当然也可以不在该脚本中配置而在启动Kafka之前对JVM运行环境进行设置，如export KAFKA_HEAP_OPTS=“${JVM优化具体配置}”。

2．启动KafkaServer

执行以下命令启动KafkaServer：

kafka-server-start.sh -daemon ../config/server.properties

首次启动成功后在$KAFKA_HOME/logs 目录下会创建相应的日志文件，相关日志文件说明如表5-1所示，同时在$log.dir目录下创建相应文件，在4.1节中有详细介绍。

表5-1　Kafka日志文件说明

	日志名称	日志说明	默认日志级别
controller.log	KafkaController运行时日志	TRACE
kafka-authorizer.log	Kafka权限认证相应操作日志	WARN
kafka-request.log	Kafka相应网络请求日志	WARN
kafkaServer-gc.log	Kafka运行过程，进行GC操作时的日志	INFO
log-cleaner.log	Kafka日志清理操作相关统计信息	INFO
server.log	KafkaServer运行日志	INFO
state-change.log	Kafka分区角色切换等状态转换日志	TRACE

分别在集群其他机器上运行此命令，启动KafkaServer。启动完毕后，登录ZooKeeper客户端查看相应节点信息。例如，查看brokers信息，执行命令及输出结果信息如下：

[zk: 172.117.12.61:2181(CONNECTED) 0] ls /brokers/ids

[1, 2, 3]

[zk: 172.117.12.61:2181(CONNECTED) 1] get /controller

{"version":1,"brokerid":1,"timestamp":"1486464201250"}

cZxid = 0x80000004e

ctime = Tue Feb 07 18:43:14 CST 2017

mZxid = 0x80000004e

mtime = Tue Feb 07 18:43:14 CST 2017

pZxid = 0x80000004e

cversion = 0

dataVersion = 0

aclVersion = 0

ephemeralOwner = 0x25a1654ae340006

dataLength = 54

numChildren = 0

[zk: 172.117.12.61:2181(CONNECTED) 2]

通过以上信息，可以看到3个节点组成的Kafka集群已成功启动，其中[1, 2, 3]分别表示这3个节点Kafka的brokerId，broker.id=1的节点作为Leader控制器。

此时假设我们杀（kill）掉broker.id=1的Kafka进程，可以看到ZooKeeper会将broker.id=1的节点从/brokers/ids中移除，同时Kafka集群会从其他两个节点中选举出一个节点作为Leader控制器。首先查看Kafka进程号，然后强制kill掉Kafka进程，操作命令如下：

[root@rhel65 bin]# jps

16097 QuorumPeerMain

16236 ZooKeeperMain

21304 Kafka

21766 Jps

[root@rhel65 bin]# kill -9 21304

再次在ZooKeeper客户端查看代理信息如下：

[zk: 172.117.12.61:2181(CONNECTED) 6] ls /brokers/ids

[2, 3]

[zk: 172.117.12.61:2181(CONNECTED) 7] get /controller

{"version":1,"brokerid":2,"timestamp":"1486464518008"}

cZxid = 0x80000005f

ctime = Tue Feb 07 18:48:38 CST 2017

mZxid = 0x80000005f

mtime = Tue Feb 07 18:48:38 CST 2017

pZxid = 0x80000005f

cversion = 0

dataVersion = 0

aclVersion = 0

ephemeralOwner = 0x15a1654ca270004

dataLength = 54

numChildren = 0

[zk: 172.117.12.61:2181(CONNECTED) 8]

由以上显示信息可知，broker.id=1的KafkaServer从集群中下线之后，集群自动选举出broker.id=2的节点作为Leader控制器。

若希望开启JMX监控，则在KafkaServer启动时需要设置JMX_PORT，可以将JMX_PORT配置添加到KafkaServer启动脚本kafka-server-start.sh文件中。例如，设置JMX_PORT端口为9999，则在启动脚本中增加以下配置：

export JMX_PORT=9999

再次启动KafkaServer，通过ZooKeeper客户端查看节点信息，可以看到该节点JMX_PORT信息为设置的9999。若不设置则JMX_PORT端口为一个无效端口−1，信息如下：

[zk: 172.117.12.61:2181(CONNECTED) 10] get /brokers/ids/1

{"jmx_port":9999,"timestamp":"1486516725492","endpoints":["PLAINTEXT://localhost:

9092"],"host":"localhost","version":3,"port":9092}

当然也可以在执行启动KafkaServer脚本时指定JMX_PORT配置，启动命令如下：

JMX_PORT=9999 kafka-server-start.sh -daemon ../config/server.properties # 开启JMX监控，指定jmx端口为9999

5.1.2　启动Kafka集群

Kafka并没有提供同时启动集群中所有节点的执行脚本，在生产中一个Kafka集群往往会有多个节点，若逐个节点启动稍微有些麻烦，在这里自定义一个脚本用来启动集群中所有节点，脚本名为kafka-cluster-start.sh，内容如代码清单5-1所示。

代码清单5-1　启动Kafka集群的脚本代码

#!/bin/bash

brokers="server-1 server-2 server-3"

KAFKA_HOME=" /usr/local/software/kafka/kafka_2.11-0.10.1.1"

echo "INFO:Begin to start kafka cluster..."

for broker in $brokers

echo "INFO:Start kafka on ${broker} ..."

ssh $broker -C "source /etc/profile; sh ${KAFKA_HOME}/bin/kafka-server-start.sh

-daemon ${KAFKA_HOME}/config/server.properties"

if [ $? -eq 0 ]; then

echo "INFO:[${broker}] Start successfully "

done

echo "INFO:Kafka cluster starts successfully!" <strong> </strong>

下面简要介绍代码清单5-1所示的启动Kafka集群的脚本代码。

首先定义了变量brokers用来保存集群中各节点的机器域名，brokers="server-1 server-2 server-3"表示机器名分别为server-1、server-2和server-3的3个节点（机器域名在/etc/host中已进行配置）。若增加或减少节点时只需修改brokers变量的值。

然后遍历brokers指定的代理列表取出每个节点，通过SSH方式登录该节点，执行${KAFKA_HOME}/bin/kafka-server-start.sh 脚本，启动Kafka。为了保证该步骤执行成功，要确保已安装配置SSH。

将kafka-cluster-start.sh脚本放在Kafka集群任何一个节点上。这里将此文件存放在broker.id=1的节点上，并给该文件赋予可执行权限，命令如下：

chmod +x kafka-cluster-start.sh # 授予可执行权限

运行kafka-cluster-start.sh脚本启动Kafka集群各节点，命令如下：

./kafka-cluster-start.sh

同时由于Kafka运行在JVM之上，因此会依赖相应系统环境配置，为了保证各环境配置在执行该脚本时已生效，在启动命令中加入了source/etc/profile命令。若不加入该命令，可能由于部分环境配置及权限设置问题导致启动失败。例如，我在初始执行该脚本试图启动Kafka集群时，启动并未成功，查看logs目录下的kafkaServer.out文件发现该文件记录以下日志内容：

nohup: failed to run command `Java': Permission denied

为了简单，这里直接在命令中加入了source/etc/profile命令，保存再次执行该脚本，Kafka集群正常启动。

脚本执行无任何报错信息提示时，通过jps查看kafka进程，查看启动日志或是登录ZooKeeper客户端来验证各节点运行情况。

5.1.3　关闭Kafka单个节点

Kafka自带了关闭Server的脚本kafka-server-stop.sh，脚本核心代码如下：

PIDS=$(ps ax | grep -i 'kafka.Kafka' | grep Java | grep -v grep | awk '{print $1}')

if [ -z "$PIDS" ]; then

echo "No kafka server to stop"

exit 1

else

kill -s TERM $PIDS

该脚本实现的功能是查找进程名为Kafka的进程的PID，然后杀掉该进程。但该脚本在某些版本的操作系统执行时并不能关闭Kafka。这里使用的操作系统为：

[root@rhel65 bin]# lsb_release -a

LSB Version:

:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch: graphics-4.0

-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch

Distributor ID: RedHatEnterpriseServer

Description: Red Hat Enterprise Linux Server release 6.5 (Santiago)

Release: 6.5

Codename: Santiago

执行kafka-server-stop.sh时，输出以下信息：

[root@rhel65 bin]# kafka-server-stop.sh

No kafka server to stop

关闭失败的原因是ps ax | grep -i 'kafka.Kafka' | grep Java | grep -v grep | awk '{print $1}'命令在我所使用的操作系统中并不能得到Kafka进程的PID：

[root@rhel65 bin]# ps ax | grep -i 'kafka.Kafka' | grep Java | grep -v grep | awk '{print $1}'

[root@rhel65 bin]#

因此这里将该脚本查找PID的命令（代码中第一行）修改如下：

PIDS=$(jps | grep -i 'Kafka' |awk '{print $1}')

通过jps命令查看进程信息，然后从输出的进程信息中查找Kafka进程信息所在的行，通过awk提取第二列即为Kafka进程的PID。修改后保存再次执行kafka-server-stop.sh脚本，脚本正常执行，查看server.log文件部分输出如下：

[2017-02-08 18:44:26,892] INFO Shutting down. (kafka.log.LogManager)

[2017-02-08 18:44:26,906] INFO Shutdown complete. (kafka.log.LogManager)

[2017-02-08 18:44:26,908] INFO [GroupCoordinator 2]: Shutting down.

(kafka.coordinator.GroupCoordinator)

[2017-02-08 18:44:26,909] INFO [ExpirationReaper-2], Shutting down