Apache Kafka 快速上手指南

1. 简介

Apache Kafka™是一个分布式流平台(a distributed streaming platform)。它被用于两大类应用：

• 建立实时流数据管道从而能够可靠地在系统或应用程序之间的共享数据
• 构建实时流应用程序，能够变换或者对数据进行相应的处理。

首先，明确几个概念：

• Kafka是运行在一个或多个服务器的集群(Cluster)上的。
• Kafka集群分类存储的记录流被称为主题(Topics)。
• 每个消息记录包含一个键，一个值和时间戳。

1.1 Kafka有四个核心API：

• 生产者 API 允许应用程序发布记录流至一个或多个Kafka的话题(Topics)。
• 消费者API 允许应用程序订阅一个或多个主题，并处理这些主题接收到的记录流。
• Streams API 允许应用程序充当流处理器（stream processor），从一个或多个主题获取输入流，并生产一个输出流至一个或多个的主题，能够有效地变换输入流为输出流。
• Connector API 允许构建和运行可重用的生产者或消费者，能够把 Kafka主题连接到现有的应用程序或数据系统

1.2 Topic

Topic 是一种分类或发布的一系列记录的名义上的名字。Kafka的 Topic 始终是支持多用户订阅的; 也就是说，一个 Topic 可以有零个，一个或多个消费者订阅写入的数据。对于每一个 Topic ，Kafka集群保持一个N分区日志文件，每个分区内的记录是严格有序的不可变序列。
Kafka集群保留所有发布的记录，不管这个记录有没有被消费过，Kafka提供可配置的保留策略去删除旧数据，Kafka的性能跟存储的数据量的大小无关， 所以将数据存储很长一段时间是没有问题的。
一台 Kafka broker 可以有多个分区，这样的好处是，每个分区可以对应一个消费者，提高了并行消费的能力。

1.3 分布式特性

数据记录日志的多个分区会尽量均匀分布在整个集群中，每个服务器会共享分区进行数据请求的处理。每个分区可以配置一定数量的副本分区提供容错能力。每个分区都有一个服务器充当“leader”和零个或多个服务器充当“followers”。 leader处理所有的读取和写入分区的请求，而followers被动的从领导者拷贝数据。如果leader失败了，followers之一将自动成为新的领导者。每个服务器可能充当一些分区的leader和其他分区的follower，这样的负载就会在集群内很好的均衡分配。
[疑问点：在集群中，进行实验来确定分区和副本的部署情况]

1.4 执行角色

生产者：
生产者发布数据到他们所选择的主题。生产者负责选择把记录分配到主题中的哪个分区。
消费者：
消费者以消费群（consumer group ）的名称来标识自己，每个发布到主题的消息都会发送给订阅了这个主题的消费群里面的一个消费者的一个实例。
消费群组：
逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据，会广播给不同的 group；同一个group中只有一个worker能拿到这个数据。换句话说，对于同一个topic，每个group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。

消费保证：
Kafka消费群的实现方式是通过分割日志的分区，分给每个Consumer实例，使每个实例在任何时间点的都可以“公平分享”独占的分区。维持消费群中的成员关系的这个过程是通过Kafka动态协议处理。如果新的实例加入该组，他将接管该组的其他成员的一些分区; 如果一个实例死亡，其分区将被分配到剩余的实例。
Kafka只保证一个分区内的消息有序，不能保证一个主题的不同分区之间的消息有序。分区的消息有序与依靠主键进行数据分区的能力相结合足以满足大多数应用的要求。但是，如果你想要保证所有的消息都绝对有序可以只为一个主题分配一个分区，虽然这将意味着每个消费群同时只能有一个消费进程在消费。

1.5 Kafka 作为消息系统

消息处理模型历来有两种：队列和发布-订阅。Kafka的消费群的推广了这两个概念。消费群可以像队列一样让消息被一组进程处理（消费群的成员），与发布 – 订阅模式一样，Kafka可以让你发送广播消息到多个消费群。Kafka的模型的优点是，每个主题都具有这两个属性，它可以扩展处理能力，也可以实现多个订阅者，没有必要二选一。

1.6 Kafka 作为存储系统

Kafka把消息数据写到磁盘和备份分区。Kafka允许生产者等待返回确认，直到副本复制和持久化全部完成才认为成功，否则则认为写入服务器失败。由于存储的重要性，并允许客户控制自己的读取位置，你可以把Kafka认为是一种特殊用途的分布式文件系统，致力于高性能，低延迟的有保障的日志存储，能够备份和自我复制。

1.7 Kafka 流处理

Kafka 提供了一个完全集成的流API。这允许应用程序把一些重要的计算过程从流中剥离或者加入流一起。流API建立在Kafka提供的核心基础单元之上：它使用生产者和消费者的API进行输入输出，使用Kafka存储有状态的数据，并使用群组机制在一组流处理实例中实现容错。

2. 快速开始

第1步：下载
进入 Apache Software 的镜像下载网站：http://apache.fayea.com/，找到 Kafka 对应的版本进行下载，在这里也能找到zookeeper，也可以从这里下载，当然也可以用Kafka自身带的一个简易版本。

> wget http://apache.fayea.com/kafka/2.3.0/kafka_2.12-2.3.0.tgz

解压的一个目录，如 /usr/local下面。

第2步：启动服务
Kafka 需要依赖使用ZooKeeper，所以你需要先启动ZooKeeper的服务器，如果你没有单独ZK服务，可以使用Kafka包装里的方便脚本来得到一个快速的单节点ZooKeeper实例。

> nohup bin/zookeeper-server-start.sh config/zookeeper.properties > /dev/null 2>&1 &

然后启动 Kafka

> nohup sbin/kafka-server-start.sh config/server.properties > /dev/null 2>&1 &

第3步：创建一个 Topic：
创建一个名为“test”主题，只有一个分区，只有一个副本：

> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

现在我们可以看到，如果我们运行的列表主题命令话题：

> bin/kafka-topics.sh --list --zookeeper localhost:2181
test

第4步：发送消息：
Kafka带有一个命令行客户端，获取从文件或来自标准输入的输入，并作为消息发送到Kafka集群。默认情况下，每一行将被作为单独的消息发送。运行生产者脚本，然后输入一些信息到控制台发送到服务器。

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
This is a message
This is another message

第5步：消费消息：
当然消费方式太多种，这里只是学习性质的，使用自带的客户端。Kafka有一个命令行消费者，将收到的消息输出到标准输出。

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
This is a message
This is another message

所有的命令行工具都有其他选项，不带参数运行命令将显示更加详细的使用信息。

3. 尝试集群

到目前为止，我们已经运行了单个节点的 broker，但是这没有乐趣。对于Kafka，一个 broker 是只有一个单节点的集群，因此多 broker 集群只是比开始多了一些 broker 实例外，没有什么太大的变化。为了感受一下，我们的集群扩展到三个节点（所有的节点还是在本地机器上）。
首先，我们为每个 borker 做一个配置文件:

> cp config/server.properties config/server-1.properties
> cp config/server.properties config/server-2.properties

现在，编辑这些新文件和设置以下属性：

config/server-1.properties:
    broker.id=1
    listeners=PLAINTEXT://:9093
    log.dir=/tmp/kafka-logs-1

config/server-2.properties:
    broker.id=2
    listeners=PLAINTEXT://:9094
    log.dir=/tmp/kafka-logs-2

该broker.id属性是集群中的每个节点的唯一和永久的名字。我们要重写端口和日志目录，因为我们都在同一台机器上运行这些 broker，我们要防止 broker 在同一端口上注册或覆盖彼此的数据。
我们已经有Zookeeper服务和我们的单个节点服务，所以我们只需要启动两个新节点：

> bin/kafka-server-start.sh config/server-1.properties &
> bin/kafka-server-start.sh config/server-2.properties &

现在，创建一个新的具有三个的副本因子的 Topic：

> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 2 --topic my-replicated-topic

好了，现在我们有一个集群，但是如何才能知道哪个代理节点在做什么？要查看运行“describe topics”命令：

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
Topic:my-replicated-topic       PartitionCount:2        ReplicationFactor:3     Configs:
        Topic: my-replicated-topic      Partition: 0    Leader: 0       Replicas: 0,1,2 Isr: 0,1,2
        Topic: my-replicated-topic      Partition: 1    Leader: 1       Replicas: 1,2,0 Isr: 1,2,0

下面是输出的解释。第一行给出了所有分区的摘要，每个附加的行提供了一个分区的信息。

• “Leader”，负责指定分区所有读取和写入的节点。每个节点将是一部分随机选择的分区中的领导者。
• “Replicas”是此分区日志的节点列表集合，不管这些节点是否是领导者或者只是还活着(不在in-sync状态)。
• “ISR”是一组”in-sync” 节点列表的集合。这个列表包括目前活着并跟leader保持同步的replicas，Isr 是Replicas的子集。

我们可以运行相同的命令看看我们创建原来的话题的状态：

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
Topic:test	PartitionCount:1	ReplicationFactor:1	Configs:
	Topic: test	Partition: 0	Leader: 0	Replicas: 0	Isr: 0

所以毫不奇怪，原来的话题没有副本，只有我们创建它时的唯一的服务器0。

让我们发布一些消息到我们新的话题：

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
message 1
message 2
message 3

现在让我们来消费这些消息：

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic
...
message 1
message 2
message 3

4. 生产环境

生产环境下肯定是要使用集群的，zookeeper也要使用集群配置来保证高可用，zookeeper 集群配置方式这里就不累述，Kafka 集群配置需要注意的地方，这里提一下。
配置文件中需要修改的地方：

broker.id=0                                              
advertised.listeners=PLAINTEXT:// 58.246.xx.xx:9092
zookeeper.connect=192.168.2.240:2181,192.168.2.241:2181,192.168.2.242:2181
log.dir=/data/kafka-logs-2

其他调优的配置，不对集群环境产生影响，这里不做解释。

5. zookeeper 存储结构

上面提到 Kafka 的配置信息和 topic 信息以及消费者信息等都是依靠 zookeeper 来管理的，在 zookeeper 中具体的存储结构我们也需要了解一下，具体可以参考这篇文章：Kafka在zookeeper中存储结构