Kafka(上)

一、Kafka概述

1、Kafka是什么

在流式计算中，Kafka一般是用来缓存数据，Storm通过消费Kafka的数据来进行计算。

• Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目
• Kafka最初是由LinkedIn公司开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台
• Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)成为broker
• 无论是Kafka集群，还是producer和consume都依赖于Zookeeper集群保存一些meta消息，来保证系统可用性

2、消息队列内部实现原理

1、点对点模式(一对一、消费者主动拉取数据，消息收到后消息清除)
点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。
2、发布订阅模式(一对多、数据产生后，推送给所有订阅者)
发布订阅模式则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。

3、为什么需要消息队列

1、解耦
允许独立扩展或者修改俩边的处理过程，只要确保它们遵守同样的接口约束
2、冗余
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3、扩展性
因为消息队列解耦了处理过程，所有增大消息入列和处理的频率是很容易的，只要另外增加处理过程即可。
4、灵活性和峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5、可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，因此即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6、顺序保证
在大多使用场景下，数据处理顺序十分重要。大部分消息队列本来就是排序的，并且能够保证数据会按照特定的顺序来处理。(Kafka保证一个partition内的消息的有序性)
7、缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况
8、异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但是不立即处理。在队列中可以任意放入消息的量，待需要的时候再去处理

4、Kafka的架构

1）Producer ：消息生产者，就是向kafka broker发消息的客户端。
2）Consumer ：消息消费者，向kafka broker取消息的客户端
3）Topic ：可以理解为一个队列。
4）Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制-给consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
5）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
7）Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

5、分布式模型

Kafka的消费者消费消息时，只保证在一个分区内的消息的完全有序性，并不保证同一个主题汇中多个分区的消息顺序。而且，消费者读取一个分区消息的顺序和生产者写入到这个分区的顺序是一致的。比如，生产者写入“hello”和“Kafka”两条消息到分区P1，则消费者读取到的顺序也一定是“hello”和“Kafka”。如果业务上需要保证所有消息完全一致，只能通过设置一个分区完成，但这种做法的缺点是最多只能有一个消费者进行消费。一般来说，只需要保证每个分区的有序性，再对消息假设键来保证相同键的所有消息落入同一分区，就可以满足绝大多数的应用。

二、Kafka集群部署

1、环境准备

http://kafka.apache.org/downloads.html下载自己需要的Kafka版本

2、Kafka集群部署

1、解压安装包

tar -zxvf kafka_2.11-0.11.0.0.tgz -C /opt/module/

2、在/opt/module/kafka目录下创建logs文件夹

mkdir logs

3、修改配置文件

vim config/server.properties
输入一下内容
#broker的全局唯一编号，不能重复
broker.id=0
#是否允许删除topic
delete.topic.enable=true
#kafka运行日志存放的路径
log.dirs=/opt/module/kafka/logs
#配置连接Zookeeper集群地址
zookeeper.connect=hadoop1:2181,hadoop2:2181,hadoop3:2181

4、配置环境变量

vim /etc/profile
#KAFKA_HOME
export KAFKA_HOME=/opt/module/kafka_2.11-0.11.0.0
export PATH=$PATH:$KAFKA_HOME/bin

使配置信息生效

source /etc/profile

5、分发安装包

xsync kafka_2.11-0.11.0.0/

6、分别在hadoop2和hadoop3上修改配置文件/opt/module/kafka_2.11-0.11.0.0/config/server.properties中的broker.id=1、broker.id=2
注：broker.id不得重复

3、Kafka命令行操作

1、查看当前服务器中所有的topic

bin/kafka-topics.sh --zookeeper hadoop1:2181 --list

2、创建topic

bin/kafka-topics.sh --zookeeper hadoop1:2181 --create --replication-factor 3 --partitions 1 --topic first

选项说明：
–topic 定义topic名字
–replication-factor 定义副本数
–partitions 定义分区数
3、删除topic

bin/kafka-topics.sh --zookeeper hadoop1:2181 --delete --topic first

需要server.properties中设置delete.topic.enable=true否则只是标记删除或者直接重启
4、发送消息

bin/kafka-console-producer.sh --broker-list hadoop1:9092 --topic first
	>hello world
	>kafka kafka

5、消费消息
在集群的另一台机器上启动

bin/kafka-console-consumer.sh --zookeeper hadoop1:2181 --from-beginning --topic first

–from-beginning：会把first主题中以往所有的数据都读取出来。根据业务场景选择是否增加该配置。
6、查看某个topic的详情

bin/kafka-topics.sh --zookeeper hadoop1:2181 --describe --topic first

三、Kafka工作流程分析

1、Kafka工作流程分析

<1>、写入方式

producer采用推(push)的模式将消息发布到broker，每条消息都被追加(append)到分区(partition)中，属于顺序写磁盘(顺序写磁盘效率比随机写内存要高，保障kafka吞吐率)

<2>、分区(Partition)

Kafka集群有多个消息代理服务器（broker-server）组成，发布到Kafka集群的每条消息都有一个类别，用主题（topic）来表示。通常，不同应用产生不同类型的数据，可以设置不同的主题。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生成者写入的新消息。
Kafka集群为每个主题维护了分布式的分区（partition）日志文件，物理意义上可以把主题（topic）看作进行了分区的日志文件（partition log）。主题的每个分区都是一个有序的、不可变的记录序列，新的消息会不断追加到日志中。分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，叫做偏移量（offset），这个偏移量能够唯一地定位当前分区中的每一条消息。

<3>、副本

同一个partition可能会有多个replication（对应 server.properties 配置中的 default.replication.factor=n）。没有replication的情况下，一旦broker 宕机，其上所有 partition 的数据都不可被消费，同时producer也不能再将数据存于其上的partition。引入replication之后，同一个partition可能会有多个replication，而这时需要在这些replication之间选出一个leader，producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据。

<4>、写入流程

producer写入消息流程如下：

1）producer先从Zookeeper的 "/brokers/…/state"节点找到该partition的leader
2）producer将消息发送给该leader
3）leader将消息写入本地log
4）followers从leader pull消息，写入本地log后向leader发送ACK
5）leader收到所有ISR中的replication的ACK后，增加HW（high watermark，最后commit 的offset）并向producer发送ACK

2、Broker保存消息

<1>、存储方式

物理上把topic分成一个或多个partition（对应 server.properties 中的num.partitions=3配置），每个partition物理上对应一个文件夹（该文件夹存储该partition的所有消息和索引文件）

<2>、存储策略

无论消息是否被消费，kafka都会保留所有消息。有俩种策略可以删除旧数据
1、基于时间：log.retention.hours=168
2、基于大小：log.retention.bytes=1073741824
需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

<3>、Zookeeper存储结构

注意：producer不在Zookeeper中注册，消费者在Zookeeper中注册

3、Kafka消费过程分析

Kafka提供了俩套consumer API：高级API和低级API

<1>、消费模型

基于推送模型（push）的消息系统，由消息代理记录消费者的消费状态。消息代理在将消息推送到消费者后，标记这条消息为已消费，但这种方式无法很好地保证消息被处理。比如，消息代理把消息发送出去后，当消费进程挂掉或者由于网络原因没有收到这条消息时，就有可能造成消息丢失（因为消息代理已经把这条消息标记为已消费了，但实际上这条消息并没有被实际处理）。如果要保证消息被处理，消息代理发送完消息后，要设置状态为“已发送”，只有收到消费者的确认请求后才更新为“已消费”，这就需要消息代理中记录所有的消费状态，这种做法显然是不可取的。
Kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序读取每个分区的消息。如下图所示，有两个消费者（不同消费者组）拉取同一个主题的消息，消费者A的消费进度是3，消费者B的消费进度是6。消费者拉取的最大上限通过最高水位（watermark）控制，生产者最新写入的消息如果还没有达到备份数量，对消费者是不可见的。这种由消费者控制偏移量的优点是：消费者可以按照任意的顺序消费消息。比如，消费者可以重置到旧的偏移量，重新处理之前已经消费过的消息；或者直接跳到最近的位置，从当前的时刻开始消费。

在一些消息系统中，消息代理会在消息被消费之后立即删除消息。如果有不同类型的消费者订阅同一个主题，消息代理可能需要冗余地存储同一消息；或者等所有消费者都消费完才删除，这就需要消息代理跟踪每个消费者的消费状态，这种设计很大程度上限制了消息系统的整体吞吐量和处理延迟。Kafka的做法是生产者发布的所有消息会一致保存在Kafka集群中，不管消息有没有被消费。用户可以通过设置保留时间来清理过期的数据，比如，设置保留策略为两天。那么，在消息发布之后，它可以被不同的消费者消费，在两天之后，过期的消息就会自动清理掉。

<2>、高级API

1、优点
写起来非常简单
不需要自行去管理offset，系统通过Zookeeper自行管理
不需要管理分区、副本等情况，系统自动管理
消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据（默认设置1分钟更新一下zookeeper中存的offset）
可以使用group来区分对同一个topic 的不同程序访问分离开来（不同的group记录不同的offset，这样不同程序读取同一个topic才不会因为offset互相影响）
2、缺点
不能自行控制offset(对于某些特殊需求来说)
不能细化控制如分区、副本、Zookeeper等

<3>、低级API

1、优点
能够让开发者自己控制offset，想从哪里读取就从哪里读取。
自行控制连接分区，对分区自定义进行负载均衡
对zookeeper的依赖性降低（如：offset不一定非要靠zk存储，自行存储offset即可，比如存在文件或者内存中）
2、缺点
太过复杂，需要自行控制offset，连接哪个分区，找到分区leader 等。

<4>、消费者组

消费者是以consumer group消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个partition。在图中，有一个由三个消费者组成的group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。
在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。

<5>、消费方式

consumer采用pull（拉）模式从broker中读取数据。
push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。
对于Kafka而言，pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。
pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞（并且可选地等待到给定的字节数，以确保大的传输大小）。

<6>、消费者组案例

需求测试通过一个消费者组中的消费者，同一个时刻只能有一个消费者消费
1、在hadoop1、hadoop2上修改/opt/module/kafka_2.11-0.11.0.0/config/consumer.properties配置文件中的group.id属性为任意组名。
2、在hadoop1、hadoop2上分别启动消费者

[1@hadoop1 kafka_2.11-0.11.0.0]$ bin/kafka-console-consumer.sh --zookeeper hadoop1:2181 --topic first --consumer.config config/consumer.properties
[1@hadoop2 kafka_2.11-0.11.0.0]$ bin/kafka-console-consumer.sh --zookeeper hadoop1:2181 --topic first --consumer.config config/consumer.properties

3、在hadoop3上启动生产者

[1@hadoop3 kafka]$ bin/kafka-console-producer.sh --broker-list hadoop1:9092 --topic first
							>hello world

4、查看hadoop1和hadoop2的接收者
同一时刻只有一个消费者接收到消息