1、Apache Kafka 介绍
Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。从下是几个常用术语。
Topics(主题)，消息流的存在形式。
Producers(生产者)
Consumers(消费者)
Broker(代理)，Kafka集群中可以包括一个或多个servers，每个server被称为broker。
下图是Kafka几个角色的交互图。消费者和生产者之间通过一种简单、高性能且语言无关的TCP协议进行通信。目前已经提供了基于多种开发语言的Kafka客户端，详见https://cwiki.apache.org/confluence/display/KAFKA/Clients。
主题和日志Topics and Logs
1) Topic是发送消息的类别或名称，kafka为每个topic维护一个分区的日志，如下所示：
每个partition是持续添加的有序的不可变的消息序列—a commit log 。partition内部的消息都被分配唯一的Id number--offset 。
2) 无论是否消费，kafka在一段可配置时间内会保留所有提交的消息。如设置2天，发布后两天内都可以消费，两天后就会腾出空间。kafka的性能是恒定量，多保留些数据不是问题。
3) 每个消费者实际需要保留的元数据信息是消费者处理log的位置-offset. offset由consumer来控制。通常随着读取messages,consumer会线性增长offset, 但实际上这个值由consumer控制，可以以喜欢的任何顺序来消费，如可以设置成一个old offset，重新处理消息。
4) 这些特性意味着kafka consumer可是做到非常轻量级，它们可以加入进来或剥离出去而基本上不会对其他consumer造成影响。（如我们可以用命令行tail等操作查看任一个topic内容，而不会改变已经存在的consumer的消费行为).
以上这些特性的好处在于首先它允许日志量超出单台服务器能力范畴,每个独立的分区必须受限于运行它的server,但是一个topic却可以有多个partition（这意味着可以持有任意数量的数据)；其次，他们作为并行单元执行。
分布式Distribution
日志分区被分布式得保存到kafka集群内的各个servers上，每个server只处理分区的一部分数据和访问请求。每个分区都跨多servers的进行数据复制以实现容错。每个Partition会有一个Leader，有0个或多个followers. leader处理这个partition的所有读写请求，followers被动的复制leader. 如果leader fails,其中一个followers自动成为leader.每个server都做一部分partition的leader和其他partition的follower,所以负载在集群上是均匀的。
生产者Producers
Producers向topics发送数据，每个producer负责选择将消息发送给topic的哪个partition。这可以用轮询的方式简单的balance load,或者基于语义partition function(如根据消息Key).
消费者Consumers
消息有两种传统使用模式：队列和发布-订阅。 队列模式下，几个消费者同时从消息服务器读取数据时，消息只会发送到其中一个消费者；发布订阅模式中，消息会广播到所有消费者。Kafka提供了一种消费者的抽象——consumer group，可以同时实现以上两种消息使用模式。
消费者给自己命名一个consumer group 名称，每个发送给topic的消息都被传递到consumer订阅组的一个consumer实例中。consumer 实例可以是一台机器上的不同独立进程，也可以是不同机器上的进程。
如果所有的consumer instance都有相同的consumer group, 类似于传统的queue，负载平均到consumers.
如果所有的consumer instance都有不同的consumer group, 类似于发布-订阅，消息将被广播到所有的consumers.
更常见的是，topics有少量的consumer group,每个逻辑订阅组一个名字。每个组为了扩展性和容错性由多个consumer instance组成。这超出了发布订阅模式语义，每个订阅者是consumer群，不是单个进程。
kafka比常见的消息系统提供了更强的排序保证。
传统队列系统，并行consumer会让本来有序的队列，消息处理顺序被打乱。如果要继续保证消息队列的有序性，那么只能通过“独占性消费者”模式来实现，而这又失去了并行处理特性。Kafka在这一点上面做得更出色，它可以保证顺序和并行处理能力。通过分配partitions给consumer group中的consumers，并保证每个partition是由consumer group中的一个consumer消费。（这样保证一个consumer是一个指定partiton的唯一reader且是按顺序消费数据。因为会划分出很多分区，所以还是能平衡负载。需要注意的是，在consumer grup中的consumer instances的数量不能多于partitions的数量.)
当然Kafka只提供了分区内部的消息有序性，不能跨一个topic的多个partitions. 结合每个partition内部消息数据的有序性和按Key划分多partitions的能力，对大多数应用都够用了。
然而，如果你的应用需要的是一个基于全部消息数据的完全的有序队列，也可以通过一种特殊的方式来达到目的。即为一个topic只划分一个partition，且在consumer group中只能有一个consumer进程。
A two serverKafka cluster hosting four partitions (P0-P3) with two consumer groups.Consumer group A has two consumer instances and group B has four.
Guarantees
(1)一个生产者向指定topic的一个partition发送的消息，将会被按消息的发送顺序追加到队列中。因此对于一个生产者先后发送的消息M1和M2，M1会比M2有一个更小的 offset，并且会更早的出现在日志中。
(2)一个consumer instance看到的消息顺序与它们在Log中存储的顺序相同。
(3)对于一个复制因子为N的topic，可以容忍N-1 server宕机不丢失数据。
2、使用场景 Use Cases
Kafka的常见使用场景。
消息队列 Messaging
Kafka可以用来平滑替换传统消息中间件，消息中间件一般是用于解耦生产者消费者和缓存未处理消息等。kafka与以往的消息中间件相比有更大的吞吐量、内置的分区和分区复制机制、容错机制，所以更适合做大型消息处理应用的解决方案。
根据以往使用kafka的经验看，常见的场景是——吞吐量并不高，但需要端到端低延迟且严格的数据持久化保证。
网站活动跟踪 Website Activity Tracking
(1)kafka的原始用途：通过重建用户跟踪管道为一组实时的发布-订阅feeds。这意味着网站活动(pv,search,用户的其他活动)根据类型被发布到中心topics（每个activity一个topic）. 这些feed广泛用于大量用例的订阅包括实时处理、实时监控、load to hadoop或者离线数据仓库为离线处理和报告。
(2)活动跟踪需要高吞吐量，因为需要为每个user page view都生成许多的活动消息。
Metrics 度量.
kafka经常用于处理监控数据，如从分布式的应用聚合统计资料以生成这些监控数据的集中式的订阅源(feeds)。
Log aggregation日志聚合
日志聚合工具会将物理的日志文件从分散的多个主机上收集过来，并放入一个集中的位置(如file server/hdfs)，以便于后续处理。
Kafka对各种日志文件的各种细节进行了抽象化处理，然后针对日志数据或事件数据提供了一个更干净、一致的消息流。Kafka提供了低延迟处理、易于支持多个数据源和分布式的数据处理（消费）的特性。相比于中心化的日志聚合系统，如scribe/flume，kafka可以在提供同样性能的条件下，实现更强的持久化保证以及更低的端到端延迟。
Stream processing流处理
在一些使用场景中，用户需要做阶段性的数据处理。用户会首先消费那些保存在Kafka topics中原始数据，然后对数据进行聚合、丰富等加工，或者干脆转换成一种新的Kafka topics用于未来的进一步处理工作。例如：一个文章推荐的处理流可能从rss源抓取文章内容，然后发布到一个文章的topic；下一阶段的处理可能会对数据进行规范化或者把这个数据复制到一个内容清洗后新的文章topic；最后阶段可能会尝试对内容和用户进行匹配的工作。这样就在本来相互独立的topics之上创建出了一个实时的数据流图。Storm和Samza是比较流行的实现这类转换的框架。
Event sourcing 事件溯源
事件溯源是一种应用设计模式，在这类应用中状态改变会被记录为一系列按时间排序的日志记录。Kafka支持非常大量的日志数据，因此非常适合做这种类型应用的后端。
Commit Log
kafka可以做为分布式系统的一种外部日志提交工具（external commit-log）。日志系统能够帮助在节点间复制数据，可以作为失败节点恢复数据时的一种数据重新同步机制。Kafka的日志压缩功能也可以帮助这种用途提供支持。
3、快速入门 Quick Start
这一部分教程是假定你是刚刚接触Kafka并且在你的测试环境中还没有使用到Kafka和ZooKeeper。
Step1: 下载安装包
>wget http://mirrors.cnnic.cn/apache/kafka/0.9.0.1/kafka_2.11-0.9.0.1.tgz
> tar -xzf kafka_2.11-0.9.0.1.tgz
> cd kafka_2.11-0.9.0.1
Step2: 启动server
Kafka需要使用到ZooKeeper，所以你如果还没有一个的话，可以暂时使用kafka提供的一个供测试使用的单节点ZooKeeper实例。
> bin/zookeeper-server-start.sh config/zookeeper.properties
接下来启动Kafka server：
> bin/kafka-server-start.sh config/server.properties
Step3: 创建一个topic
创建一个名为”test”的topic，设置为一个分区、一个副本。
> bin/kafka-topics.sh --create --zookeeper localhost:2181--replication-factor 1 --partitions 1 --topic test
使用list命令查看刚刚创建的topic：
> bin/kafka-topics.sh --list --zookeeper localhost:2181
test
此外也可以配置为当提交到不存在的topic时，broker自动创建该topic。
http://kafka.apache.org/documentation.html#quickstart_send
Step 4: 发送消息 Send somemessages
Kafka提供了命令行工具从文件获取输入或者标准输入 ，作为消息发送到kafka集群，默认一行一个消息。
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topictest
Step 5: 启动一个消费者 Start aconsumer
Kafka提供了命令行工具，可以人队列中取出消息并输出到终端屏幕上。
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test--from-beginning
这时，你就可以在发送端输入消息，观察消费端的输出。
Step 6: 建立一个多节点的Kfaka集群 Setting up a multi-broker cluster
我们接下来把这个单实例的kfaka变成一个三节点的集群。
> 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
port=9093
log.dir=/tmp/kafka-logs-1
config/server-2.properties:
broker.id=2
listeners=PLAINTEXT://:9094
port=9094
log.dir=/tmp/kafka-logs-2
broker.id是集群中每个节点的唯名称。同时我们必须修改每个broker实例使用的监听端口和日志名称。因为在这个测试用例中，三个kafka broker节点都部署在一台机器上。
启动两个新的kafka broker节点：
> 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
查看每个broker都在做些什么：
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topicmy-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是处理所有消息读写的节点。Replicas是所有数据冗余复制节点的列表，无论这些节点是否可用都会显示出来。Isr表示正在保持与leader数据同步的节点列表。我们可以看到在这个例子中，node1是这个topic唯一一个分区的leader节点。
我们继续查看前面创建的topic——test：
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topictest
Topic:test PartitionCount:1 ReplicationFactor:1 Configs:
Topic: test Partition: 0 Leader:0 Replicas: 0 Isr: 0
果然，这个topic是位于server 0上面的。因为这个topic只有一个分区、复制因子为1且在创建时我们仅启动了server0 。
向my-replicated-topic可写几条测试数据：
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topicmy-replicated-topic
...
my test message 1
my test message 2
接下来是启动一个消费者：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181--from-beginning --topic my-replicated-topic
测试容错性，杀掉server-1. (Leader):
> ps -ef | grep server-1.properties
Kill掉进程。
Kafka集群的leadership自动进行了切换：
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topicmy-replicated-topic
继续测试发、收消息，服务仍然在正常运行。即使原来的leader节点已经当掉了。
Step 7: 使用Kafka Connect实现数据的导入/导出 Use Kafka Connect to import/export data
Kafka 0.9+增加了一个新的特性 Kafka Connect ,可以更方便的创建和管理数据流管道。它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型，通过connectors 可以将大数据从其它系统导入到Kafka中，也可以从Kafka中导出到其它系统。Kafka Connect可以将完整的数据库注入到Kafka的Topic中，或者将服务器的系统监控指标注入到Kafka，然后像正常的Kafka流处理机制一样进行数据流处理。而导出工作则是将数据从Kafka Topic中导出到其它数据存储系统、查询系统或者离线分析系统等，比如数据库、Elastic Search 、 Apache Ignite 等。它包含两个功能，数据集成和流处理。Kafka Connect则是为数据集成而生。
Kafka Connect特性包括：
n Kafka connector通用框架,提供统一的集成API
n 同时支持分布式模式和单机模式
n REST 接口，用来查看和管理Kafka connectors
n 自动化的offset管理，开发人员不必担心错误处理的影响
n 分布式、可扩展
n 流/批处理集成
Kafka已经成为处理大数据流的平台标准， 成千上万的公司在使用它 。程序员在构建它们的平台的时候也遇到一些问题：Schema管理、容错、并行化、数据延迟、分发担保、运营与监控。这些棘手的问题都要程序员去处理，如果有一个统一的框架去完成这些事情，将可以大大减少程序员的工作量，因此Kafka 0.9中提供了这一特性，负责处理这些问题。
Kafka Connnect有两个核心概念：Source和Sink。 Source负责导入数据到Kafka，Sink负责从Kafka导出数据，它们都被称为Connector。Kafka背后的公司confluent鼓励社区创建更多的开源的connector，将Kafka生态圈壮大起来，促进Kafka Connnect的应用。
当前Kafka Connect支持两种分发担保：at least once (至少一次) 和 at most once(至多一次)，exactly once将在未来支持。
当前已有的Connectors包括：
| Connector Name | Owner | Status |
| Community project | ||
| In progress | ||
| Community project | ||
| In progress | ||
| In progress | ||
| Community project | ||
| Community project | ||
| In progress | ||
| In progress | ||
| Community project (Planned for Apache Ignite 1.6 Release) |
Connectors的发布和开发可以参照 官方文档 。
http://www.confluent.io/developers/connectors
http://kafka.apache.org/documentation.html#connect
我们接下来使用终端命令行工具对Kafka Connect做一个简单的测试和演示：
1）创建一个用于测试的文件
>cd /usr/local/kafka_2.11-0.9.0.1
> echo -e "foo\nbar" > test.txt
2）启动两个单实例模式的connector
>bin/connect-standalone.sh config/connect-standalone.propertiesconfig/connect-file-source.properties config/connect-file-sink.properties
在上面的三个参数中，
connect-standalone.properties，是Kafka Connect进程使用的配置文件，通常包含需要连接的broker信息和对数据进行序列化的格式配置；
connect-file-source.properties和connect-file-sink.properties，定义了两个需要被创建出来的connector，包含connector name、使用到的工作类、topics的命名（这里是取命为了connect-test）以及输入输出文件名等配置信息。
3）测试connector管道
> echo "Another line" >> test.txt
向源文件test.txt中追加写入更多内容时，实时观察另一个Connector的输出文件:
> tail -f test.sink.txt
4）我们也可以在终端上另启动一个消费者来查看在上面使用的topic中的消息数据
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topicconnect-test --from-beginning
{"schema":{"type":"string","optional":false},"payload":"foo"}
{"schema":{"type":"string","optional":false},"payload":"bar"}
{"schema":{"type":"string","optional":false},"payload":"Anotherline"}
{"schema":{"type":"string","optional":false},"payload":"Anotherline 2."}
{"schema":{"type":"string","optional":false},"payload":"Anotherline 3."}
{"schema":{"type":"string","optional":false},"payload":"connectormessage test 1."}
{"schema":{"type":"string","optional":false},"payload":"connectormessage test 2."}
4、生态 Ecosystem
目录已经有大量的主发行版之外的与kafka实现整合的工具。在Kafka生态系统页列出了很多，包括：数据流系统、hadoop集成、监控、部署工具等。以下是主流的一部分kafka集成工具的列表。| 工具名称 | 描述 | 备注 |
| Kafka Connect | Kafka has a built-in framework called Kafka Connect for writing sources and sinks that either continuously ingest data into Kafka or continuously ingest data in Kafka into external systems. The connectors themselves for different applications or data systems are federated and maintained separately from the main code base. You can find a list of them here. |
|
| Stream Processing |
|
|
| Hadoop Integration |
|
|
| Search and Query |
|
|
| Management Consoles |
|
|
| Logging |
|
|
| Flume - Kafka plugins |
|
|
2083
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
