深入学习kafka

为什么需要消息系统

1.解耦：

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2.冗余：

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

3.扩展性：

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。

4.灵活性 & 峰值处理能力:

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

5.可恢复性：

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

6.顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消息的有序性）

7.缓冲：

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

8.异步通信：

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

kafka的前世今生

官网是这样说的:

kafka是一个具备很强容错能力和实时处理能力的分布式流数据平台

kafka背景:

期初linkedin采用了ActiveMQ来进行数据交换，大约是在2010年前后，那时的ActiveMQ还远远无法满足linkedin对数据传递系统的要求，经常由于各种缺陷而导致消息阻塞或者服务无法正常访问，为了能够解决这个问题，linkedin决定研发自己的消息传递系统。当时的linkedin的首席架构师jay kreps 组织团队研发的

kafka名字的由来：

由于jay kreps非常喜欢franz kafka（弗兰兹·卡夫卡），因此取了个和消息传递系统完全不相干的名称kafka，取名字是并没有特别的含义

kafka的主要特点

高吞吐量：低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，百MB/s吞吐，接近网卡的极限。
可扩展性：kafka集群支持热扩展。
持久性:可靠性，消息直接持久化在普通磁盘上且性能好，支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）。
高并发：单点支持上千个客户端同时读写。
灵活性：消息被处理的状态是在consumer端维护。消费方式非常灵活，第一原因是消息持久化时间跨度比较长，一天或者一星期等，第二消费状态自己维护消费到哪个地方了可以自定义消费偏移量。

Kafka使用场景

消息系统：kafka更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息，等），与大多数消息系统比较，kafka有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息。在这一领域的kafka比得上传统的消息系统，比如ActiveMQ或RabbitMQ。

日志聚合:许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件，并将它们放在中央位置（可能是文件服务器或HDFS）进行处理。Kafka抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。

用户活动跟踪: Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告

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

事件采集: 事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，kafka支持这种非常大的存储日志数据的场景。

Kafka基本机制

Kafka术语介绍

1、消息生产者：即Producer，是消息的产生的源头，负责生成消息并发送到Kafka服务器上。
生产者也负责选择发布到Topic上的哪一个分区。最简单的方式从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。
2、消息消费者：即Consumer，是消息的使用方，负责消费Kafka服务器上的消息。
消息模型可以分为两种， 队列和发布-订阅式。 队列的处理方式是 一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组 （consumer group）。 消费者用一个消费者组名标记自己。 一个发布在Topic上消息被分发给此消费者组中的一个消费者。 假如所有的消费者都在一个组中，那么这就变成了queue模型。 假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。 更通用的， 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者， 一个组内多个消费者可以用来扩展性能和容错。如下图：

Topic 中的4个partition在Consumer Group A中的分配情况如下：C1 订阅p0,p3；C2 订阅p1,p2
Topic 中的4个partition在Consumer Group B中的分配情况如下：C3 订阅p0；C4 订阅p3；C5 订阅p1；C6 订阅p2

3、主题：即Topic，由用户定义并配置在Kafka服务器，用于建立生产者和消息者之间的订阅关系：生产者发送消息到指定的Topic下，消息者从这个Topic下消费消息。
4、消息分区：即 ，一个Topic下面会分为很多分区，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
5、Broker：即Kafka的服务器，用户存储消息，Kafa集群中的一台或多台服务器统称为 broker。
6、消费组：若干个Consumer组成的集合。这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个CG只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
7、offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息.

Kafka 分区与生产者，消费者的关系

生产者发送消息到主题，消费者订阅主题（以消费者组的名义订阅），而主题下是分区，消息是存储在分区中的，所以事实上生产者发送消息到分区，消费者则从分区读取消息，那么，这里问题来了，生产者将消息投递到哪个分区？消费者组中的消费者实例之间是怎么分配分区的呢？*
1、主题的分区数设置
在server.properties配置文件中可以指定一个全局的分区数设置，这是对每个主题下的分区数的默认设置，默认是1。
2、 生产者与分区，生产者将消息投递到分区策略
2.1、默认的分区策略：如果在发消息的时候指定了分区，则消息投递到指定的分区（–partitions n）
如果没有指定分区，但是消息的key不为空，则基于key的哈希值来选择一个分区
如果既没有指定分区，且消息的key也是空，则用轮询的方式选择一个分区。
3、消费者分区分配策略
3.1、range策略：是基于每个主题的，对于每个主题，我们以数字顺序排列可用分区，以字典顺序排列消费者。然后，将分区数量除以消费者总数，以确定分配给每个消费者的分区数量。如果没有平均划分（除不尽），那么最初的几个消费者将有一个额外的分区。
也就是说：
1、range分配策略针对的是主题（这里所说的分区指的某个主题的分区，消费者指的是订阅这个主题的消费者组中的消费者实例）
2、首先，将分区按数字顺序排行序，消费者按消费者名称的字典序排好序
3、然后，用分区总数除以消费者总数。如果能够除尽，则皆大欢喜，平均分配；若除不尽，则位于排序前面的消费者将多负责一个分区

Kafka 分区与生产者，消费者的关系

3.2、roundrobin（轮询）：基于所有可用的消费者和所有可用的分区的
1. 消费者按照字典排序，例如C0, C1, C2… …，并构造环形迭代器。 2. topic名称按照字典排序，并得到每个topic的所有分区，从而得到所有分区集合。 3. 遍历第2步所有分区集合，同时轮询消费者。 4. 如果轮询到的消费者订阅的topic不包括当前遍历的分区所属topic，则跳过；否则分配给当前消费者，并继续第3步

如图所示：
3个Topic：T0（3个分区0, 1, 2）, T1（两个分区0, 1）, T2（4个分区0, 1, 2, 3）；
3个consumer: C0订阅了[T0, T1]， C1订阅了[T1, T2]， C2订阅了[T2, T0]；
roundrobin结果分配结果如下：
T0-P0分配给C0，T0-P1分配给C2，T0-P2分配给C0， T1-P0分配给C1，T1-P1分配给C0， T2-P0分配给C1，T2-P1分配给C2，T2-P2分配给C1，T0-P3分配给C2；
推算过程：
分区T0-P0，消费者C0，C0订阅了这个分区所在Topic即T0，所以T0-P0分配给C0；
轮询到下一个分区T0-P1和下一个消费者C1； 分区T0-P1，消费者C1，C1没有订阅T0，取下一个消费者C2，C2订阅了T0，所以T0-P1分配给C2；
轮询到下一个分区T0-P2和下一个消费者C0； 分区T0-P2，消费者C0，C0订阅了T0，所以T0-P2分配给C0；
轮询到下一个分区T1-P0和下一个消费者C1； 分区T1-P0，消费者C1，C1订阅T1，所以T1-P0分配给C1； 以此类推即可。

主题和日志 (Topic和Log):

Topic是发布的消息的类别或者订阅源名称。对于每一个Topic，Kafka集群维护这一个分区的log，就像下图中的示例:
每一个分区都是一个顺序的、不可变的消息队列， 并且可以持续的添加。分区中的消息都被分了一个序列号，称之为偏移量(offset)，在每个分区中此偏移量都是唯一的。
Kafka集群保持所有的消息，直到它们过期， 无论消息是否被消费了。 实际上消费者所持有的仅有的元数据就是这个偏移量，也就是消费者在这个log中的位置。 这个偏移量由消费者控制：正常情况当消费者消费消息的时候，偏移量也线性的的增加。但是实际偏移量由消费者控制，消费者可以将偏移量重置为更老的一个偏移量，重新读取消息。 可以看到这种设计对消费者来说操作自如， 一个消费者的操作不会影响其它消费者对此log的处理。

producer 写入消息序列图如下所示：

1. producer 先从 zookeeper 的 “/brokers/…/state”
   节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
5. leader 收到所有 ISR(In-Sync Replicas) 中的 replica 的 ACK 后，
   commit 的 offset 并向 producer 发送 ACK。
   

Kafka 安装使用

Step 1: 下载代码
下载地址：

> tar -xzf kafka_2.11-1.1.0.tgz> cd kafka_2.11-1.1.0
> cd kafka_2.11-1.1.0

Step 2: 启动服务

> nohup bin/zookeeper-server-start.sh config/zookeeper.properties > zookeeper-run.log 2>&1 &
[2019-05-24 13:28:36,431] INFO Reading configuration from: config/zookeeper.properties           (org.apache.zookeeper.server.quorum.QuorumPeerConfig)……………………..

**现在启动kafka服务

nohup bin/kafka-server-start.sh config/server.properties > kafka-run.log 2>&1 &
[2019-07-22 17:34:07,954] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2019-07-22 17:34:07,958] INFO autopurge.snapRetainCount set to 3 (org.apache.zookeeper.server.DatadirCleanupManager)…

Step 3: 创建一个主题(topic)
创建一个名为“test”的Topic，只有一个分区和一个备份：

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

创建好之后，可以通过运行以下命令，查看已创建的topic信息：
bin/kafka-topics.sh --list --zookeeper 172.16.101.70:2181
test

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

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

bin/kafka-console-producer.sh --broker-list 172.16.101.70:9092 --topic test

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

bin/kafka-console-consumer.sh --bootstrap-server 172.16.101.70:9092 --topic test --from-beginning

Step 6: 设置多个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
启动：
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 172.16.101.70:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
查看topic详情：
bin/kafka-topics.sh --describe --zookeeper 172.16.101.70:2181 --topic my-replicated-topic

Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 0 Replicas: 0,2,1 Isr: 0,1,2

“leader”：该节点负责该分区的所有的读和写，每个节点的leader都是随机选择的。
“replicas”：备份的节点列表，无论该节点是否是leader或者目前是否还活着，只是显示。
“isr”：“同步备份”的节点列表，也就是活着的节点并且正在同步leader。
我们要测试集群的容错，kill掉leader，Broker0作为当前的leader，也就是kill掉Broker0
发布一些信息在新的topic上：
bin/kafka-console-producer.sh --broker-list 172.16.101.70:9092 --topic my-replicated-topic
…
my test message 1
my test message 2

消费消息：

bin/kafka-console-consumer.sh --zookeeper 172.16.101.70:2181 --from-beginning --topic my-replicated-topic
…
my test message 1
my test message 2

测试集群的容错，kill掉leade：

ps -ef|grep server.properties
kill -9 13818
java.io.IOException: Connection to localhost:9092 (id: 0 rack: null) failed…………………
备份节点之一成为新的leader:
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: 0,2,1 Isr: 1,2

消息仍然没丢：
bin/kafka-console-consumer.sh --bootstrap-server 172.16.101.70:9093 --topic my-replicated-topic --from-beginning

…

kafka存储:

Kafka具有存储功能，默认保存数据时间为7天或者大小1G，也就是说kafka broker上的数据超7天或者1G，就会被清理掉。这些数据存放在broker服务器上，以log文件的形式存在。
log的路径配置在conf/server.properties配置文件中，log文件的命名那一长串0，是这个日志文件的offset位置。当日志文件达到时间或者大小的上限时，就会生成下一个日志文件，命名的就是下一个offset位置了。

查看日志内容：log日志文件是二进制文件，无法通过文本查看，但是可以通过kafka.tools.DumpLogSegments类的方法，可以查看日志的内容。

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files /tmp/kafka-logs/my-replicated-topic-0/00000000000000000000.log --print-data-log

消息和offset存储:
consumer的offset存储有两种方式,一种是存放在broker的日志目录中，另一种方式是存放在zookeeper中。两种存放方式和你使用kafka-console-consumer命令使用的选项有关。如果使用的是bootstrap-server，那么就存放在broker；如果使用的是–zookeeper那么就存放在zookeeper。
broker存储offset:
broker存放offset是kafka从0.9版本开始，提供的新的消费方式。原因是zookeeper来存放，还是有许多弊端，不方便灵活控制，效率不高。
kafka有四个核心API:
应用程序使用 Producer API 发布消息到1个或多个topic（主题）。
应用程序使用 Consumer API 来订阅一个或多个topic，并处理产生的消息。
应用程序使用 Streams API 充当一个流处理器，从1个或多个topic消费输入流，并生产一个输出流到1个或多个输出topic，有效地将输入流转换到输出流。
Connector API允许构建或运行可重复使用的生产者或消费者，将topic连接到现有的应用程序或数据系统。例如，一个关系数据库的连接器可捕获每一个变化。

kafka生产者API
配置属性：
生产者的缓冲空间池保留尚未发送到服务器的消息，后台I/O线程负责将这些消息转换成请求发送到集群。如果使用后不关闭生产者，则会泄露这些资源。

kafka消费者API：
配置：

官网其他配置详解：http://kafka.apache.org/documentation.html#configuration

自动提交偏移量：

手动提交偏移量：不需要定时的提交offset，可以自己控制offset，当消息认为已消费过了，这个时候再去提交它们的偏移量。这个很有用的，当消费的消息结合了一些处理逻辑，这个消息就不应该认为是已经消费的，直到它完成了整个处理。

指定偏移量手动提交：
手动提交commitSync表示所有收到的消息为”已提交"，在某些情况下，你可以希望更精细的控制，通过指定一个明确消息的偏移量为“已提交”

订阅指定的分区：
我们订阅我们感兴趣的topic，让kafka提供给我们平分后的topic分区。但是，在有些情况下，你可能需要自己来控制分配指定分区.
例如：
如果这个消费者进程与该分区保存了某种本地状态（如本地磁盘的键值存储），则它应该只能获取这个分区的消息。
如果消费者进程本身具有高可用性，并且如果它失败，会自动重新启动。 在这种情况下，不需要Kafka检测故障，重新分配分区，因为消费者进程将在另一台机器上重新启动。

一旦手动分配分区，你可以在循环中调用poll（跟前面的例子一样）。消费者分组仍需要提交offset，只是现在分区的设置只能通过调用assign修改，因为手动分配不会进行分组协调，因此消费者故障不会引发分区重新平衡。注意，手动分配分区（即，assgin）和动态分区分配的订阅topic模式（即，subcribe）不能混合使用

Kafka Connect概述:

Kafka Connect 是一个可扩展、可靠的在Kafka和其他系统之间流传输的数据工具。它可以通过connectors（连接器）简单、快速的将大集合数据导入和导出kafka。Kafka Connect可以接收整个数据库或收集来自所有的应用程序的消息到Kafka Topic。使这些数据可用于低延迟流处理。导出可以把topic的数据发送到secondary storage（辅助存储也叫二级存储）也可以发送到查询系统或批处理系统做离线分析。Kafka Connect功能包括：
Kafka连接器通用框架：Kafka Connect 规范了kafka与其他数据系统集成，简化了connector的开发、部署和管理。
分布式和单机模式 - 扩展到大型支持整个organization的集中管理服务，也可缩小到开发，测试和小规模生产部署。
REST 接口 - 使用REST API来提交并管理Kafka Connect集群。
自动的offset管理 - 从connector获取少量的信息，Kafka Connect来管理offset的提交，所以connector的开发者不需要担心这个容易出错的部分。
分布式和默认扩展 - Kafka Connect建立在现有的组管理协议上。更多的工作可以添加扩展到Kafka Connect集群。
流/批量集成 - 利用kafka现有的能力，Kafka Connect是一个桥接流和批量数据系统的理想解决方案。

使用 Kafka Connect 来 导入/导出 数据
从控制台写入和写回数据是一个方便的开始，但你可能想要从其他来源导入或导出数据到其他系统。
Kafka Connect是导入和导出数据的一个工具:

创建一些“种子”数据用来测试:

echo -e “foo\nbar” > test.txt
bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties
echo “Another line” >> test.txt
[root@localhost kafka_2.11-2.2.0]# bin/kafka-console-consumer.sh --bootstrap-server 172.16.101.70:9092 --topic connect-test --from-beginning
{“schema”:{“type”:“string”,“optional”:false},“payload”:“foo”}
{“schema”:{“type”:“string”,“optional”:false},“payload”:“bar”}
{“schema”:{“type”:“string”,“optional”:false},“payload”:“Another line”}

Kafka jdbc Connect mysql增量同步

在kafka lib 文件夹中添加两个jar包，mysql-connector-java-5.1.40.jar，kafka-connect-jdbc-4.1.1.jar，在config中添加如下两个文件。

source：quickstart-mysql.properties

sink：quickstart-mysql-sink.properties

winds启动kafka，启动connect
命令：
启动kafka：.\bin\windows\kafka-server-start.bat .\config\server.properties
启动zookeeper：.\bin\windows\zookeeper-server-start.bat .\config\zookeeper.properties
创建topic：kafka-run-class.bat kafka.admin.TopicCommand --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic mysql-kafka-person
启动connect：connect-standalone.bat D:/kafka/kafka_2.12-1.1.0/config/connect-standalone.properties D:/kafka/kafka_2.12-1.1.0/config/quickstart-mysql.properties D:/kafka/kafka_2.12-1.1.0/config/quickstart-mysql-sink.properties
源数据a库中person插入数据：INSERT INTO a.person(firstname, age) VALUES (‘2’, 3);
b库中会导入相应的数据：

使用Kafka Stream来处理数据

Kafka Stream是kafka的客户端库，用于实时流处理和分析存储在kafka broker的数据，
流处理持续获取输入topic的数据，进行处理加工，然后写入输出topic。例如，一个零售APP，接收销售和出货的输入流，统计数量或调整价格后输出。

创建名为streams-plaintext-input的输入主题和名为streams-wordcount-output的输出主题:

bin/kafka-topics.sh --create
–zookeeper 172.16.101.70:2181
–replication-factor 1
–partitions 1
–topic streams-plaintext-input
Created topic “streams-plaintext-input”.

bin/kafka-topics.sh --create
–zookeeper 172.16.101.70:2181
–replication-factor 1
–partitions 1
–topic streams-wordcount-output
–config cleanup.policy=compact
Created topic “streams-wordcount-output”

启动Wordcount应用程序:

bin/kafka-run-class.sh org.apache.kafka.streams.examples.wordcount.WordCountDemo
应用程序将从输入主题stream-plaintext-input读取，对每个读取消息执行WordCount算法的计算，并连续将其当前结果写入输出主题streams-wordcount-output。
使用控制台的producer 将输入的数据发送到指定的topic（streams-file-input）中:
bin/kafka-console-producer.sh --broker-list 172.16.101.70:9092 --topic streams-plaintext-input
all streams lead to kafka
hello kafka streams
在单独的终端中使用控制台使用者读取其输出主题来检查WordCount演示应用程序的输出:
bin/kafka-console-consumer.sh --bootstrap-server 172.16.101.70:9092
–topic streams-wordcount-output
–from-beginning
–formatter kafka.tools.DefaultMessageFormatter
–property print.key=true
–property print.value=true
–property key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
–property value.deserializer=org.apache.kafka.common.serialization.LongDeserializer

kafka与zookeeper:

Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

1)Producer端直接连接broker.list列表,从列表中返回TopicMetadataResponse,该Metadata包含Topic下每个partition leader建立socket连接并发送消息.
2)Broker端使用zookeeper用来注册broker信息,以及监控partition leader存活性.
3)Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。

Zookeeper作用：

管理broker、consumer
1)创建Broker后，向zookeeper注册新的broker信息，实现在服务器正常运行下的水平拓展。具体的，通过注册watcher，获取partition的信息。
2)Topic的注册，zookeeper会维护topic与broker的关系，通/brokers/topics/topic.name节点来记录。
。Zookeepr不管理producer，只是能够提供当前broker的相关信息。


Consumer可以使用group形式消费kafka中的数据。Zookeeper管理consumer的offset跟踪当前消费的offset。