Kafka：概述、体系架构、Kafka集群部署、命令行操作、工作流程
目录
1、Kafka(0.10.0.1)概述
1.1、消息队列JMS
1.2、消息队列的优点
1.3、Kafka是什么
2、Kafka体系架构
1）消息 / 键 / 批次 2）Topic
3）Producer 4）Consumer
5）Consumer Group 6）Partition
7）brocker
3、Kafka集群部署
4、Kafka命令行操作
5、Kafka工作流程
5.1、写入方式
1）分区 2）复本 3）流程
5.2、Broker保存消息
1）存储方式
2）存储策略
3）Zookeeper存储结构
5.3、消费行为
1）consumer API
2）消费者组
3）消费方式
1、Kafka(0.10.0.1)概述
1.1、消息队列JMS
1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。
2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的 订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。
1.2、消息队列的优点
1）异步处理
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
2）应用解耦/扩展性/可恢复性
允许独立地扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束；
因为消息队列解耦了处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可；
系统的一部分组件失效时，不会影响到整个系统，加入队列中的消息仍然可以在系统恢复后被处理。
3）流量消峰/缓冲
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃；
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
4）顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。磁盘顺序读写比内存随机访问效率更高。
5）冗余
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
1.3、Kafka是什么
Kafka是一个分布式、支持分区的、多复本的、基于zookeeper协调的分布式消息系统。
1）最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写。在流式计算中，Kafka 一般用来缓存数据，SparkStreaming通过消费Kafka的数据进行计算。
2）Kafka是一个分布式消息队列，具有生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。相当于结合了JMS的两个模式：Producer以订阅的方式向brocker推送topic；Consumer以抓取的方式从brocker中抓取topic
3）Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。
4）无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性
Kafka与消息队列对比
Kafka是一个流平台，在这个平台上可以发布和订阅数据流，并把它们保存起来、进行处理，这是构建Kafka的初衷。
Kafka有些类似消息系统，但Kafka以集群的方式运行，可以自由伸缩；
作为数据连接层，Kafka提供了数据传递保证，即可复制、持久化，保存多久都可以；
消息系统只会传递消息，而Kafka的流式处理能力能够很动态地处理派生流和数据集；
Kafka与flume对比
flume
适合多个生产者；（一个生产者对应一个 Agent 任务）
适合下游数据消费者不多的情况；（多 channel 多 sink 会耗费很多内存）
适合数据安全性要求不高的操作；（实际中更多使用 Memory Channel）
适合与 Hadoop 生态圈对接的操作。（Cloudera 公司的特长）
kafka
适合数据下游消费者众多的情况；（开启更多的消费者任务即可，与 Kafka 集群无关）
适合数据安全性要求较高的操作，支持replication。（数据放在磁盘里）
因此我们常用的一种模型是：
线上数据 --> flume(适合采集tomcat日志) --> kafka(离线/实时) --> flume(根据情景增删该流程) --> HDFS
Kafka与Hadoop对比
Kafka与可以看成是实时版的Hadoop，Hadoop可以存储和定期处理大量的数据文件，而Kafka可以存储和持续处理大型的数据流，它们之间的最大不同体现在持续的低延迟处理和批处理之间的差异上。Hadoop和大数据应用主要用于数据分析，而Kafka因其低延迟的特点更适合用在核心的业务应用上
Kafka与ETL工具对比
Kafka并非只是把数据从一个系统拆解出来再塞到另一个系统，它其实是一个面向实时数据流的平台。也就是说，它不仅可以将现有的应用程序和数据系统连接起来，还能够用于加强这些触发相同数据流的应用
2、Kafka体系架构
1）消息 / 键 / 批次
Kafka中的数据单元被称为消息。消息由字节数组组成，可理解为数据库中的一条"记录"；
消息可以由一个可选的元数据，也就是键，键也是一个字节数组。键与消息对于Kafka来说没什么特殊的含义；
当消息以一种可控的方式写入不同的分区时会用到键，比如为键生成一个一致性散列值，然后使用散列值对topic分区数进行取模，为消息选取分区；
为了提高效率，消息被分批次写入Kafka。批次就是一组消息，这些消息属于同一topic和分区。批次大小的选择需要在时间延迟和吞吐量之间做出权衡
2）Topic
主题可理解为一个队列。Kafka的消息通过topic进行分类，topic就像是数据库中的"表"。topic可以被分成若干个分区(类似HBase中建表时预分区)，一个分区对应一个提交日志。消息以追加的方式写入分区，然后以FIFO进行顺序读取，每个分区内的顺序是确定的
3）Producer
消息生产者，向 broker 推送消息的客户端。一个消息会被发布到一个特定的topic上，producer默认会将消息均衡地分布到主题的所有分区上(Hash分区器)
4）Consumer
消息消费者，向 broker 抓取消息的可独断。Consumer可以抓取同一个topic中的不同分区，并按照消息生成的顺序读取
Consumer通过检查消息的offset来区分已经读取过的消息。
offset是一种元数据，是一个不断递增的整数值，在创建消息时被添加到消息中。在一个分区内，每个消息的offset是唯一的。consumer将每个分区最后读取的消息offset保存在zookeeper或kafka中，若consumer关闭或重启它的读取状态不会丢失。
5）Consumer Group
消费者是消费组的一部分，会有一个或多个consumer共同读取一个主题。消费组保证每个分区只能被一个consumer使用。主要用来提高consumer的可靠性，一个consumer失效可由同个CG中的consumer顶替。
Consumer Group还是 kafka 用来实现一个 topic 消息的广播（发给所有的 consumer）和单播（发给任意一个 consumer）的手段。一个 topic 可以有多个 CG。topic 的消息会被抓取到所有的 CG，但每个 partion 只会把消息发给该 CG 中的一个 consumer。如果需要实现广播，只要每个consumer 有一个独立的 CG 就可以了；实现单播只要所有的 consumer 在同一个 CG。
6）Partition
为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。将消息发给consumer，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序。
leader/follower
每个分区对应一个leader，根据(复本数-1)决定了follower的数量，leader的选举由zookeeper决定。在producer写消息时只负责向leader中写，leader负责向follower节点发送数据进行复本冗余
分区的好处
实现负载均衡。分区对于消费者来说，可以提高并发度，提高效率。若针对于某一个 topic有n个分区，我们就对应的建一个有m个消费者的消费者组。即：n大于或者等于m，最好是n=m。当n>m时，就意味着某一个消费者会消费多个分区的数据。不仅如此，一个消费者还可以消费多个 Topic 数据
7）brocker
一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
brocker接受来自producer的消息，为消息设置offset，并提交消息到磁盘保存；并对consumer读取分区的请求作出响应，返回已经提交到磁盘上的信息
注意，复本数不能大于brocker数(这与hdfs不同)
3、Kafka集群部署
单机版与伪分布式略，以下为完全分布式的搭建
属性：http://kafka.apache.org/documentation.html#configuration
1）集群规划
| master1 |
slave1 | slave2 |
| zk | zk | zk |
| kafka(brocker)*2 | kafka(brocker)*2 | - |
2）解压kafka_2.10-0.11.0.2.tgz
3）配置环境变量$KAFKA_HOME、$PATH
4）修改$KAFKA_HOME/config下配置文件server.properties
由于我规划中一台机器中有两个brocker(模拟伪分布，通常一个节点对应一个brocker)，则对应两个配置文件，server-1.properties、server-2.properties。以下为一个节点中的配置，另一个节点类推
#broker的全局唯一编号，不能重复
broker.id=0 #第二个配置文件broker.id=1
#kafka运行日志存放的路径,若在同一个机器上多个brocker,日志目录不可相同
log.dirs=/home/jinge/apps/kafka/tmp/logs/master1-0 #第二个配置文件/home/jinge/apps/kafka/tmp/logs/master1-1
#kafka中自带了zookeeper，若使用独立zk需配置连接Zookeeper集群地址
zookeeper.connect=master1:2181,slave1:2181,slave2:2181
#生产者连接该brocker端口号
listeners=PLAINTEXT://master1:9092 #第二个配置文件PLAINTEXT://master1:9093
#删除topic功能使能,默认为false删不了topic
delete.topic.enable=true
#处理网络请求的线程数量
num.network.threads=3
#用来处理磁盘IO的线程数量
num.io.threads=8
#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400
#接收套接字的缓冲区大小
socket.receive.buffer.bytes=102400
#请求套接字的缓冲区大小
socket.request.max.bytes=104857600
#topic在当前broker上的分区个数
num.partitions=1
#用来恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1
#segment文件保留的最长时间，超时将被删除（单位小时）
log.retention.hours=168
5）配置$KAFKA_HOME/config/zookeeper.properties
#与其他使用到zk的组件目录保持一致
dataDir=/home/jinge/apps/zookeeper/tmp/zookeeper
clientPort=2181
maxClientCnxns=0
6）发送kafka至其他节点，注意broker.id的设置不得重复
7）分别在不同机器上开启kafka-server(broker)
#启动Kafka是一个阻塞进程，会打印我们操作kafka的日志，我们可以把窗口放到后台，在命令后面加一个与&符号，将该阻塞进程放到后台。
@master1 kafka]$ kafka-server-start.sh config/server-1.properties &
@master1 kafka]$ kafka-server-start.sh config/server-2.properties &
@slave1 kafka]$ kafka-server-start.sh config/server-1.properties &
@slave1 kafka]$ kafka-server-start.sh config/server-2.properties &8）关闭kafka-server
#当一个节点有多个brocker也可以一起关闭
kafka-server-stop.sh stop附：kafka集群开启/关闭脚本(根据实际情况修改)
#开
#!/bin/sh
for host in master1 slave1
do
ssh $host "source ~/.bash_profile;nohup kafka-server-start.sh /home/jinge/apps/kafka/config/server.properties >/dev/null 2>&1 &"
echo "$host kafka is running"
done
#关
#! /bin/sh
for host in master1 slave1
do
ssh $host "source ~/.bash_profile; /home/jinge/apps/kafka/bin/kafka-server-stop.sh"
echo "$host kafka is stopping"
done
4、Kafka命令行操作
1）查看当前服务器中的所有topic
kafka-topics.sh --zookeeper master1:2181 --list2）创建topic
kafka-topics.sh --zookeeper master1:2181 --create --replication-factor 3 --partitions 1 --topic test- --topic 定义topic名
- --replication-factor 定义复本数（复本数不能大于节点数，否则会报错！）
- --partitions 定义分区数
3）删除topic
kafka-topics.sh --zookeeper master1:2181 --delete --topic test
需要server.properties中设置delete.topic.enable=true
4）发送消息（生产者连接的是kafka集群默认的端口号是：9092）
确保开启可brocker(kafka-server)后
$ kafka-console-producer.sh --broker-list master1:9092 --topic test
> hello
> 1235）消费消息
kafka-console-consumer.sh --zookeeper master1:2181 --from-beginning --topic test注意：消费者会将自己的 offset 文件保存在 zookeeper(低版本的kafka)。所以消费者连接的是 zookeeper。高版本中使用--bootstrap-server XXX.9092代替
- --from-beginning：会把topic中以往所有的数据都读取出来。根据业务场景选择是否增加该配置。如果不加该配置，那么消费者消费的消息将是最新的消息(不包括以往的所有数据)。
6）查看某个topic的详情
$ kafka-topics.sh --zookeeper master1:2181 --describe --topic test
Topic:test PartitionCount:3 ReplicationFactor:3 Configs:
Topic: test Partition: 0 Leader: 0 Replicas: 0,2,3 Isr: 0,3,2
Topic: test Partition: 1 Leader: 1 Replicas: 1,3,0 Isr: 0,1,3
Topic: test Partition: 2 Leader: 2 Replicas: 2,0,1 Isr: 0,1,2
高版本的kafka中，消费者会将自己的 offset文件 保存在 kafka 集群的本地，不交给 zookeeper 维护了。这样做提高了效率，减少了网络传输
5、Kafka工作流程
5.1、写入方式
producer 采用推（push）模式将消息发布到 broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）
1）分区
消息发送时都被发送到一个 topic，其本质就是一个目录，而topic是由一些 Partition Logs(分区日志)组成，每个 Partition 中的消息都是有序的，生产的消息被不断追加到 Partition log 上，其中的每一个消息都被赋予了一个唯一的 offset值。
分区规则
1）指定了 patition，则直接使用
2）未指定 patition 但指定 key，通过对 key 的 value 进行 hash 出一个 patition
3）patition 和 key 都未指定，使用轮询选出一个 patition
2）复本
同一个 partition 可能会有多个 replication（对应 server.properties 配置中的 default.replication.factor=N）。没有 replication 的情况下，一旦 broker 宕机，其上所有 patition 的数据都不可被消费，同时 producer 也不能再将数据存于其上的 partition。引入 replication 之后，同一个 partition 可能会有多个 replication，而这时需要在这些 replication 之间选出一个 leader，producer 和 consumer 只与这个 leader 交互，其它 replication 作为 follower 从leader 中复制数据。
3）流程
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
5.2、Broker保存消息
1）存储方式
物理上把 topic 分成一个或多个 patition（对应 server.properties 中的num.partitions=3配置），每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件），见上
2）存储策略
无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据(server.properties中)：
1）基于时间：log.retention.hours=168 （单位是小时，168小时即7天）
2）基于大小：log.retention.bytes=1073741824
需要注意的是，因为 Kafka 读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。
3）Zookeeper存储结构
producer 不在zk中注册，消费者在zk中注册
5.3、消费行为
1）consumer API
kafka提供了两套 consumer API：高级 Consumer API 和低级 Consumer API
- 高级API优点
高级 API 写起来简单；不需要自行去管理 offset，系统通过 zookeeper 自行管理。
不需要管理分区、副本等情况，系统自动管理。
消费者断线会自动根据上一次记录在 zookeeper 中的 offset 去接着获取数据（默认设置1分钟更新一下 zookeeper 中存的 offset）。
可以使用 group 来区分对同一个 topic 的不同程序的访问分离开来（不同的 group 记录不同的 offset，这样不同程序读取同一个 topic 才不会因为 offset 互相影响）。
- 高级API缺点
不能自行控制offset（对于某些特殊需求来说）。
不能细化控制如分区、副本、zk等。
- 低级 API 优点
能够让开发者自己控制 offset，想从哪里读取就从哪里读取；自行控制连接分区，对分区自定义进行负载均衡。
对 zookeeper 的依赖性降低（如：offset 不一定非要靠zk存储，自行存储 offset 即可，比如存在文件或者内存中）。
- 低级API缺点
太过复杂，需要自行控制 offset，连接哪个分区，找到分区 leader 等。
2）消费者组
消费者是以 consumer group 消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个 topic。每个分区在同一时间只能由 group 中的一个消费者读取，但是多个 group 可以同时消费这个 partition。在图中，有一个由三个消费者组成的 group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。
在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的 group 成员会自动负载均衡读取之前失败的消费者读取的分区。
3）消费方式
consumer采用 pull（拉）模式从 broker 中读取数据。
push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。
对于 Kafka 而言，pull 模式更合适，它可简化 broker 的设计，consumer 可自主控制消费消息的速率，同时 consumer 可以自己控制消费方式–即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。
pull 模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞（并且可选地等待给定的字节数，以确保传输大小）。