Kafka简介 & 特性 & 工作流程

Kafka简介 & 特性 & 软件安装包下载

官网：http://kafka.apache.org/
Kafka可以用于做消息队列
A distributed streaming platform (分布式的流处理平台)
Kafka原来就是一个队列，但是现在Kafka的功能越来越强大了，因为现在Kafka已经是一个分布式的流处理平台了
我们做流处理，可以使用Storm来实现，也可以使用Spark Streaming来实现，同时也可以使用Kafka来实现(因为目前Kafka是分布式的流处理平台了)
但是，目前国内使用Kafka去做流处理的不多，基本没有使用这一套的(Storm最多，之后Spark Streaming)

特性

publish & subscribe
发布和订阅
需要什么东西就订阅一下，当有新的东西过来之后，你订阅课就可以直接进行消费了
process
能够写这种可以扩展的流处理应用程序，去做实时的流处理
store
流数据能够存储进来，以安全(这个安全包括好几个方面，比如数据丢不丢失等)、分布式、多副本、容错的这些方式存储进来

kafka被使用过去构建实时的data pipeline 和 streaming apps。它能够做到水平扩展、容错的、相当快的，在许多公司会运行在生产环境上(其实在国内，做流处理的话，至少70%的公司会选用到Kafka)

Kafka介绍

官网：http://kafka.apache.org/intro
1.能够让你发布和订阅stream里面的记录(这和传统意义上的队列是一样的)
2.能够刚你存储stream里的records 以容错的方式(后面会讲kafka到底体现在哪些容错的方面)
3.能够让你再一发生的时候就立刻处理stream的records

Kafka适合用在哪些方面：

构建一个实时数据的pipeline操作
构建一个流处理的应用程序

First a few concepts:

Kafka能够在1个或者多个server上面作为集群进行运行
Kafka集群能够存储stream的records，这些记录可以分类(这里每一个分类可以理解为topic)
topic ： category
比如说：优酷上面有很多分类，每一个分类就是一个topic
每个record是由key、value、timestamp构成的

Kafka既然有订阅和发布，那么就会有生产和消费：

The Producer API允许应用程序发布stream的record到1个或者多个Kafka的topic
The Consumer API允许应用程序订阅1个或者多个topic，然后处理stream的record

高级别的Kafka给了我们如下的保障措施：

Messages sent by a producer to a particular topic partition will be appended in the order they are sent.
That is, if a record M1 is sent by the same producer as a record M2,
and M1 is sent first, then M1 will have a lower offset than M2 and appear earlier in the log.
A consumer instance sees records in the order they are stored in the log.
For a topic with replication factor N, we will tolerate up to N-1 server failures without losing any records committed to the log.

版本选择 & 下载

Kafka版本：
kafka_2.11-1.0.0.tgz (2.11是scala的版本，1.0.0是kafka的版本)
这次选择所使用的版本：kafka_2.11-0.9.0.0.tgz

扫描二维码关注公众号，回复： 1035894 查看本文章

Kafka下载：
解压到/opt/app/下
$>tar -xzvf /opt/software/kafka_2.11-0.9.0.0.tgz -C /opt/app/

$KAFKA_HOME/bin下有用的shell脚本：

kafka-topics.sh
kafka-server-start.sh
kafka-server-stop.sh

测试时候用的：

kafka-console-consumer.sh
kafka-console-producer.sh

Kafka工作流程

提出问题：如果让你自己去实现一个消息订阅与发布的系统，该如何去实现呢？
我们将一步一步去完善设计的流程，从而理解Kafka的工作流程

准备：
在工作中的日志通常有两大类：
a ) 访问日志(access)
b) ugc日志(和费用相关)

最low的版本，参考图 v1.0.png ：

生产者A ==生产==> access
生产者A ==生产==> ugc

产生的日志丢到Linux机器里去

通常情况下，生产出来的数据先到内存中(不可能直接与磁盘打交道的)，再到磁盘中去

后面由消费者进行消费：消费者1、消费者2

这种架构的缺点：
假设现在只有1台机器，把所有的日志都丢到1台机器上来了
==> 会引发1个问题：
　　如果数据非常大，会怎么办？
　　机器肯定是扛不住的
针对v1.0架构设计的解决方案，参考图 v2.0.png ：

采用分布式
如图中所示，有2台机器
==> 提出问题：2台机器上的数据是存一样还是不一样？
　　必然是存不一样的

生产者A ==生产==> 机器1：access partition0 + 机器2：access partition1
生产者A ==生产==> 机器1：ugc partition0 + 机器2：ugc partition1
生产者A生产数据，将access分开，存取到Linux机器1与机器2中(每个机器中的数据都不同)
生产者B也是如此

将一个大的数据以多partition的方式分开存储在各个机器上

v2.0的设计方式与v1.0的设计方式进行对比，好处在哪里？
==> 负载明显是小很多
　　假设：原来进来100G的数据，那么所有的书都是落在1台机器上
　　　　　现在的话，有2台机器的话，负载会小很多
==> 但是，同样带来了1个问题：
　　存在着单点的问题
　　虽然，我们将1份数据拆成了多partition组成的
　　但是，我们的每份数据都是单partition的(如图，partition0只有在1个地方有，partition1也是)
==> 因此，这种方式仍然是不行的
针对v2.0架构设计的解决方案，参考图 v3.0.png：

将Linux机器1上的access partition0放一份到机器2上 ==> partition0的副本
将Linux机器2上的access partition1放一份到机器1上 ==> partition1的副本
ugc同理

这样改进之后，容错性好很多
但是，生产者生产数据，到底是把哪一个partition的数据丢到哪个地方(决定哪个partition)
在MapReduce中，默认的partition是什么样的规则？
==> 对key取hash，然后对reduce的数量取模(这样保证了，相同的key被分到同一个reduce上面去)
　　那么在Kafka中是怎么样的呢？(这点将在后续文章中进行剖析)

总结：
Producer,Topic,Broker,Consumer概念 & Kafka工作流程：
　　Producer把我们的数据生产，丢到Topic里面，Consumer去把数据从Topic里面拿出来进行消费
　　Linux机器就是Broker(即Kafka中的server，即每个Server就是Broker)

Topic与Partition之间的关系：
　　1个topic有n个partition
　　1个partition有n个副本