Kafka 快速入门

转载声明

https://www.orchome.com/6
https://blog.csdn.net/yjt520557/article/details/88558065

Kafuka 概述

定义

Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。

消息队列

消息队列的应用场景

同步处理就是没哟适用消息队列的清空，异步处理就是使用了消息队列的清空。上面是一个简单的用户注册业务。当用户注册成功后需要给用户手机发一条短息。告诉用户你注册成功了。如果我们 适用同步的方式来处理 这个问题。就会带来一个问题。当用户 指向到第 2 步也就是 注册信息写入数据库，这是用户其实已经注册成功了，只是还没给这个用户发短信。假设发送短信是一个比较耗时的操作。那么用户要等系统将短信发送完成才能跳转到响应成功页面。当网站注册人数大的时候那么对服务器就很不友好了。这时我们可以使用一个消息中间件 也就是消息队列来决绝这个问题。当将用户注册到数据库中后，不立刻发短信。而是将发送短信这个请求写让消息队列中，然后直接页面响应成功。后台单独开一个线程，去处理消息队列中的请求。这是就大大提高了网站的抗压能力。

使用消息队列的好处

1） 解耦
允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2）可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所
以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
3）缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致
的情况。

4）灵活性 & 峰值处理能力

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃

消息队列的两种模式

（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

（2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费

发布/订阅模式分为两种：

消息队列主动推送：
可能造成消费者处理能力不足，直接崩掉。或者消费者处理能力过剩，资源浪费

消费者主动拉取：
按照消费者自己的消费速度去拉取就完事了。但是 消费者要维护一个长轮询去看看消息队列中有没有消息。所以对性能有一定损耗。

(kafka:是消费者主动消费，也就是基于拉取的消息队列，消费速度由消费者自己决定)

kafka 架构

下面带大家收悉一下kafka的架构吧：

Producer ：消息生产者，就是向 kafka broker 发消息的客户端；

Consumer ：消息消费者，向 kafka broker 取消息的客户端；

Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负
责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。可以将消费者组当成一个大的消费团体。主要的作用就是提高并非能力。

Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker
可以容纳多个 topic。

Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；

Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对
象都是 leader。

follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据
的同步。leader 发生故障时，某个 follower 会成为新的 follower。

zookeeper：是帮助kafka存储一些信息。帮助我们管理整个集群 , zookeeper也会保存消费者的消费信息，保存当前消费者消费到那条消息了，消费者内存也会保存，当消费者挂掉了就去zookeeper里面找 （存储消费者位置信息）

注：0.9 版本之前 offset 存储在 zk中，0.9版本及之后保存在本地，本地是指kafka某一个主题里面，存在磁盘中（默认存储7天）

更详细的介绍请参考：https://www.orchome.com/5

安装和简单使用

安装

下载kafka

wegt https://archive.apache.org/dist/kafka/1.0.0/kafka_2.11-1.0.0.tgz

解压：

tar -zxvf kafka_2.11-1.0.0.tgz 
mv kafka-1.1.0-src/ kafka
cd kafka

启动服务

运行kafka需要使用Zookeeper，下面使用kafka自带打包和配置好的Zookeeper。

> bin/zookeeper-server-start.sh config/zookeeper.properties

启动kafka服务

 bin/kafka-server-start.sh config/server.properties &

创建一个主题(topic)

创建一个名为“test”的Topic，只有一个分区和一个备份:

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

创建好之后，可以通过运行以下命令，查看已创建的topic信息：

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

或者，除了手工创建topic外，你也可以配置你的broker，当发布一个不存在的topic时自动创建topic。

发送消息

Kafka提供了一个命令行的工具，可以从输入文件或者命令行中读取消息并发送给Kafka集群。每一行是一条消息。运行producer（生产者）,然后在控制台输入几条消息到服务器。

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

消费消息

Kafka也提供了一个消费消息的命令行工具，将存储的信息输出出来。

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

如果你有2台不同的终端上运行上述命令，那么当你在运行生产者时，消费者就能消费到生产者发送的消息。

集群配置

Kafka 支持两种模式的集群搭建：可以在单机上运行多个 broker 实例来实现集群，也可在多台机器上搭建集群，下面介绍下如何实现单机多 broker 实例集群，其实很简单，只需要如下配置即可。

单机多broker 集群配置

首先为每个broker创建一个配置文件:

> 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在同一端口上注册和覆盖对方的数据。

我们已经运行了zookeeper和刚才的一个kafka节点，所有我们只需要在启动2个新的kafka节点。

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

现在，我们创建一个新topic，把备份设置为：3

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

好了，现在我们已经有了一个集群了，我们怎么知道每个集群在做什么呢？运行命令“describe topics”

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

输出解释：第一行是所有分区的摘要，其次，每一行提供一个分区信息，因为我们只有一个分区，所以只有一行。
leader：该节点负责该分区的所有的读和写，每个节点的leader都是随机选择的。
replica：备份的节点列表，无论该节点是否是leader或者目前是否还活着，只是显示。
isr：“同步备份”的节点列表，也就是活着的节点并且正在同步leader。

我们运行这个命令，看看一开始我们创建的那个节点：

> 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

这并不奇怪，刚才创建的主题没有Replicas，并且在服务器“0”上，我们创建它的时候，集群中只有一个服务器，所以是“0”。

让我们来发布一些信息在新的topic上：

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

现在，消费这些消息。

> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
 ...
my test message 1
my test message 2
^C

我们要测试集群的容错，kill掉leader，Broker1作为当前的leader，也就是kill掉Broker1。

> ps -ef | grep server-1.properties
7564 ttys002    0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java... 
> kill -9 7564

备份节点之一成为新的leader，而broker1已经不在同步备份集合里了。

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

但是，消息仍然没丢：

> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
^C

多机多 broker 集群配置

分别在多个节点按上述方式安装 Kafka，配置启动多个 Zookeeper 实例。
假设三台机器 IP 地址是 ： 192.168.122.140， 192.168.122.141， 192.168.122.142
分别配置多个机器上的 Kafka 服务，设置不同的 broker id，zookeeper.connect 设置如下:

zookeeper.connect=192.168.122.140:2181,192.168.122.141:2181,192.168.122.142:2181

使用 Kafka Connect 来导入/导出数据

从控制台写入和写回数据是一个方便的开始，但你可能想要从其他来源导入或导出数据到其他系统。对于大多数系统，可以使用kafka Connect，而不需要编写自定义集成代码。

Kafka Connect是导入和导出数据的一个工具。它是一个可扩展的工具，运行连接器，实现与自定义的逻辑的外部系统交互。在这个快速入门里，我们将看到如何运行Kafka Connect用简单的连接器从文件导入数据到Kafka主题，再从Kafka主题导出数据到文件。

首先，我们首先创建一些“种子”数据用来测试:

echo -e "foo\nbar" > test.txt

接下来，我们开始2个连接器运行在独立的模式，这意味着它们运行在一个单一的，本地的，专用的进程。我们提供3个配置文件作为参数。首先是Kafka Connect处理的配置，包含常见的配置，例如要连接的Kafka broker和数据的序列化格式。其余的配置文件都指定了要创建的连接器。包括连接器唯一名称，和要实例化的连接器类。以及连接器所需的任何其他配置。

> bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

kafka附带了这些示例的配置文件，并且使用了刚才我们搭建的本地集群配置并创建了2个连接器：第一个是源连接器，从输入文件中读取并发布到Kafka主题中，第二个是接收连接器，从kafka主题读取消息输出到外部文件。

在启动过程中，你会看到一些日志消息，包括一些连接器实例化的说明。一旦kafka Connect进程已经开始，导入连接器应该读取从

test.txt

和写入到topic

connect-test

导出连接器从主题

connect-test

读取消息写入到文件

test.sink.txt

我们可以通过验证输出文件的内容来验证数据数据已经全部导出：

more test.sink.txt
foo
bar

注意，导入的数据也已经在Kafka主题

connect-test

里,所以我们可以使用该命令查看这个主题：

bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic connect-test --from-beginning
{"schema":{"type":"string","optional":false},"payload":"foo"}
{"schema":{"type":"string","optional":false},"payload":"bar"}

连接器继续处理数据，因此我们可以添加数据到文件并通过管道移动：

echo "Another line" >> test.txt

你应该会看到出现在消费者控台输出一行信息并导出到文件。

使用 Kafka 流来处理数据

Kafka Streams 是用于构建关键任务实时应用程序和微服务的客户端库，输入和/或输出数据存储在 Kafka 集群中。Kafka Streams 结合了在客户端编写和部署标准 Java 和 Scala 应用程序的简单性以及 Kafka 服务器端集群技术的优势，使这些应用程序具有高度可伸缩性，弹性，容错性，分布式等特性。

官网入门案例：http://kafka.apache.org/10/documentation/streams/quickstart