Kafka快速入门

Kafka快速入门

一.消息队列

(一)消息队列介绍

    消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
    消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

(二)常用的消息队列介绍

1.RabbitMQ

    RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

2.ActiveMQ

    ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

3.RocketMQ

    RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理等。

4.Kafka

    Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

5.常用消息队列对比

(三)消息队列的应用场景

1. 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
2. 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
3. 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
4. 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；

下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用：

1.异步处理

具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。
(1)串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；

在这种方式下，需要最终发送验证短信后再返回给客户端。
(2)并行处理：新注册信息写入后，由发短信和发邮件并行处理；

在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。
假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：
串行：50+50+50=150ms
并行：50+50 = 100ms

(三)使用消息队列：

    在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；

2.应用耦合

具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示：

该方法有如下缺点：

• 人脸识别系统被调失败，导致图片上传失败；
• 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
• 图片上传系统与人脸识别系统之间互相调用，需要做耦合；

若使用消息队列：

    客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。
    此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

3.限流削峰

具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。

该方法有如下优点：

• 请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲,极大地减少了业务处理系统的压力；
• 队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；

4.消息驱动的系统

具体场景：用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。

该方法有如下优点：

• 避免了直接调用下一个系统导致当前系统失败；
• 每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；

(四)消息队列的两种模式

消息队列包括两种模式，点对点模式(point to point， queue)和发布/订阅模式(publish/subscribe，topic)。

1.点对点模式

点对点模式下包括三个角色：

• 消息队列
• 发送者 (生产者)
• 接收者（消费者）
  
  ​ 消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

点对点模式特点：

• 每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
• 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
• 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息。

2.发布/订阅模式

发布/订阅模式下包括三个角色：

• 角色主题（Topic）
• 发布者(Publisher)
• 订阅者(Subscriber)
  
  发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

发布/订阅模式特点：

• 每个消息可以有多个订阅者；
• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
• 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

二.Kafka的基本介绍

官网：http://kafka.apache.org/

(一)Kafka简介

    Kafka是最初由linkedin公司开发的，使用scala语言编写，Kafka是一个分布式，分区的，多副本的，多订阅者的日志系统（分布式MQ系统），可以用于搜索日志，监控日志，访问日志等。
    官网的介绍: Kafka is a distributed,partitioned,replicated commit logservice(译: Kafka是分布式、分区、可复制的提交日志服务)。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。Kafka对消息保存时根据Topic进行归类，发送消息者成为Producer，消息接受者成为Consumer。此外，kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

(二)Kafka的好处

• 可靠性：分布式的，分区，可复制和容错的。
• 可扩展性：kafka消息传递系统轻松缩放，无需停机。
• 耐用性：kafka使用分布式提交日志，这意味着消息会尽可能快速的保存在磁盘上，因此它是持久的。
• 性能：kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息，他也爆出稳定的性能。
• kafka非常快：保证零停机和零数据丢失。

(三)分布式的发布与订阅系统

    Apache Kafka是一个分布式发布-订阅消息系统和一个强大的队列，可以处理大量的数据，并使能够将消息从一个端点传递到另一个端点，Kafka适合离线和在线消息消费。Kafka消息保留在磁盘上，并在集群内复制以防止数据丢失。Kafka构建在Zookeeper同步服务之上。它与Apache和Spark非常好的集成，应用于实时流式数据分析。

(四)Kafka的主要应用场景

• 指标分析

  Kafka通常用于操作监控数据。这设计聚合来自分布式应用程序的统计信息，以产生操作的数据集中反馈。

• 日志聚合解决方法

  Kafka可用于跨组织从多个服务器收集日志，并使他们以标准的格式提供给多个服务器。

• 流式处理

  流式处理框架(Spark，Storm，Flink)重主题中读取数据，对齐进行处理，并将处理后的数据写入新的主题，供用户和应用程序使用，Kafka的强耐久性在流处理的上下文中也非常的有用。

三Kafka的架构介绍

• 生产者API

  允许应用程序发布记录流至一个或者多个kafka的主题(topics)。

• 消费者API

  允许应用程序订阅一个或者多个主题，并处理这些主题接收到的记录流。

• StreamsAPI

  允许应用程序充当流处理器(stream processor)，从一个或者多个主题获取输入流，并生产一个输出流到一个或 者多个主题，能够有效的变化输入流为输出流。

• ConnectAPI

  允许构建和运行可重用的生产者或者消费者，能够把kafka主题连接到现有的应用程序或数据系统。例如：一个连 接到关系数据库的连接器可能会获取每个表的变化。

(一)kafka架构内部细节剖析

说明：kafka支持消息持久化，消费端为模型来拉取数据，消费状态和订阅关系由客户端负责维护，消息消费完 后，不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了。

• Broker：kafka集群中包含一个或者多个服务实例，这种服务实例被称为Broker
• Topic：每条发布到kafka集群的消息都有一个类别，这个类别就叫做Topic
• Partition：Partition是一个物理上的概念，每个Topic包含一个或者多个Partition
• segment：一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件，其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置
• .log:存放数据文件
• .index：存放.log文件的索引数据
• Producer：负责发布消息到kafka的Broker中
• Consumer：消息消费者，向kafka的broker中读取消息的客户端
• Consumer Group：每一个Consumer属于一个特定的Consumer Group(可以为每个Consumer指定 groupName)

(二)kafka主要组件说明

1.Producer

    Producer主要是用于生产消息，是kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去。

2.Topic

• kafka将消息以topic为单位进行归类
• topic特指kafka处理的消息源(feeds of messages)的不同分类。
• topic是一种分类或者发布的一些列记录的名义上的名字。kafka主题始终是支持多用户订阅的；也就是说，一个主题可以有零个，一个或者多个消费者订阅写入的数据。
• 在kafka集群中，可以有无数的主题。
• 生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。

3.Partition

    kafka当中，topic是消息的归类，一个topic可以有多个分区，每个分区保存部分topic的数据，所有的partition当中的数据全部合并起来，就是一个topic当中的所有的数据。
    那么，一个broker服务下，是否可以创建多个分区？
    可以的，broker数与分区数没有关系； 在kafka中，每一个分区会有一个编号：编号从0开始。
    每一个分区的数据是有序的。
    如何保证一个主题下的数据是有序的？(生产是什么样的顺序，那么消费的时候也是什么样的顺序)

    topic的Partition数量在创建topic时配置。

    Partition数量决定了每个Consumer group中并发消费者的最大数量。

​如下图，Consumer group A 有两个消费者来读取4个partition中数据；Consumer group B有四个消费者来读取4个 partition中的数据。

4.Partition的副本数说明

kafka分区副本数（kafka Partition Replicas)

副本数（replication-factor）：控制消息保存在几个broker服务器上，一般情况下等于broker的个数。

    那么，一个broker服务下，是否可以创建多个副本因子？
    不可以；创建主题时，副本因子应该小于等于可用的broker数。如下副本因子过程图

    副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本；
    主副本叫做leader，从副本叫做 follower（在有多个副本的情况下，kafka会为同一个分区下的所有分区，设定角色关系：一个leader和N个 follower），处于同步状态的副本叫做in-sync-replicas(ISR);
    follower通过拉的方式从leader同步数据。
    消费者和生产者都是从leader读写数据，不与follower交互。
    副本因子的作用：增强kafka读取数据和写入数据时的可靠性。
    副本因子是包含本身，同一个副本因子不能放在同一个Broker中。

    如果某一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个leader，但不会在其 他的broker中，另启动一个副本（因为在另一台启动的话，存在数据传递，只要在机器之间有数据传递，就会长时间占用网络IO，kafka是一个高吞吐量的消息系统，这个情况不允许发生）所以不会在零个broker中启动。
    如果所有的副本都挂了，生产者如果生产数据到指定分区的话，将写入不成功。
    lsr表示：当前可用的副本

5.segment

    一个partition当中由多个segment文件组成，每个segment文件，包含两部分，一个是.log文件，另外一个是.index文件，其中.log文件包含了我们发送的数据存储，.index文件，记录的是我们.log文件的数据索引值，以便于我们加快数据的查询速度。

索引文件与数据文件的关系
    既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址。比如索引文件中3,497代表：数据文件中的第三个message,它的偏移地址为497。再来看数据文件中，Message 368772表示：在全局partiton中是第368772个message。
注：segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。

6.offset

    任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），
​ offset是一个long类型数字，它唯一标识了一条消息，消费者通过（offset，partition，topic）跟踪记录。

7.Partition与消费组的关系

• 消费组：由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。对于消费组来说，应该小于等于被消费的主题下的分区数。比如：某一个主题有4个分区，那么消费组中的消费者应该小于等于4，而且最好与分区数成整数倍1、2、4
• 同一个分区下的数据，在同一时刻，不能被同一个消费组的不同消费者消费

总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能。

8.consumer

    consumer是kafka当中的消费者，主要用于消费kafka当中的数据，任何一个消费者都必定需要属于某一个消费组当中，任意时刻，一个分区当中的数据，只能被kafka当中同一个消费组下面的一个线程消费。

四.Kafka集群环境搭建

(一)初始化环境准备

Kafka集群强依赖zookeeper，安装Kafka之前一定要保证zookeeper启动成功，且服务正常运行

(二)下载安装包并上传解压

通过以下地址进行下载安装包，在node01执行以下命令，下载并解压。

cd /export/softwares
wget http://archive.apache.org/dist/kafka/1.0.0/kafka_2.11-1.0.0.tgz
tar –zxvf  kafka_2.11-1.0.0.tgz -C /export/servers/

(三)node01服务器修改kafka配置文件

node01执行以下命令进入到kafka的配置文件目录，修改配置文件

#node01执行以下命令创建数据文件存放目录
mkdir -p  /export/servers/kafka_2.11-1.0.0/logs

cd /export/servers/kafka_2.11-1.0.0/config
vim server.properties

server.properties需修改的为:

broker.id=0
log.dirs=/export/servers/kafka_2.11-1.0.0/logs
zookeeper.connect=node01:2181,node02:2181,node03:2181
delete.topic.enable=true
host.name=node01

(四)安装包分发到其他服务器上面去

node01执行以下命令，将node01服务器的kafka安装包发送到node02和node03服务器上面去。

cd /export/servers/
scp -r kafka_2.11-1.0.0/ node02:$PWD
scp -r kafka_2.11-1.0.0/ node03:$PWD

(五)node02与node03服务器修改配置文件

node02服务器

cd /export/servers/kafka_2.11-1.0.0/config
vim server.properties

修改如下内容:

broker.id=1
host.name=node02

node03服务器

cd /export/servers/kafka_2.11-1.0.0/config
vim server.properties

修改如下内容:

broker.id=2
host.name=node03

(六)kafka集群启动与停止

启动

三台服务器都要执行如下命令:

cd /export/servers/kafka_2.11-1.0.0
nohup bin/kafka-server-start.sh config/server.properties 2>&1 &

停止

三台服务器都要执行如下命令:

cd /export/servers/kafka_2.11-1.0.0
bin/kafka-server-stop.sh

五.Kafka集群操作

启动Kafka集群, 三台服务器都要执行如下命令:

cd /export/servers/kafka_2.11-1.0.0
nohup bin/kafka-server-start.sh config/server.properties 2>&1 &

(一)创建topic

创建一个名字为test的主题, 有三个分区, 有两个副本, 在node01执行以下命令来创建topic

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh \
--create \
--zookeeper node01:2181,node02:2181,node03:2181 \
--replication-factor 2 \
--partitions 3 \
--topic test

(二)查看主题命令

查看Kafka当中存在的主题, 在node01使用以下命令来查看kafka当中存在的topic主题

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh  \
--list \
--zookeeper node01:2181

(三)生产者生产数据

模拟生产者来生产数据, 在node01服务器执行以下命令来模拟生产者进行生产数据

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-console-producer.sh --broker-list node01:9092,node02:9092,node03:9092 --topic test

(四)消费者消费数据

在node02服务器执行以下命令来模拟消费者进行消费数据

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-console-consumer.sh \
--from-beginning \
--topic test  \
--zookeeper node01:2181,node02:2181,node03:2181

(五)运行describe topics命令

在node01执行以下命令运行describe查看topic的相关信息

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh \
--describe \
--zookeeper node01:2181 \
--topic test

结果说明：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FnTPR6TS-1646200142597)(C:/MarkDown_Photo/图片79.png)]

第一行给出了所有分区的摘要，每个附加行提供有关一个分区的信息。由于我们只有一个分区用于此主题，因此只有一行。

• “leader”是负责给定分区的所有读取和写入的节点。每个节点将成为随机选择的分区部分的领导者。（因为在kafka中 如果有多个副本的话，就会存在leader和follower的关系，表示当前这个副本为leader所在的broker是哪一个）
• “replicas”是复制此分区日志的节点列表，无论它们是否为领导者，或者即使它们当前处于活动状态。（所有副本列表0 ，1，2）
• “isr”是“同步”复制品的集合。这是副本列表的子集，该列表当前处于活跃状态并且已经被领导者捕获。（可用的列表数）

(六)增加topic分区数

任意kafka服务器执行以下命令可以增加topic分区数

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh \
--zookeeper node01:2181,node02:2181,node03:2181 \
--alter \
--topic test \
--partitions 8

(七)增加配置

动态修改kakfa的配置, 任意kafka服务器执行以下命令可以增加topic分区数

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh \
--zookeeper node01:2181 \
--alter \
--topic test \
--config flush.messages=1

(八)删除配置

动态删除kafka集群配置

cd /export/servers/kafka_2.11-1.0.0

bin/kafka-topics.sh \
--zookeeper node01:2181,node02:2181,node03:2181 \
--alter \
--topic test \
--delete-config flush.messages

(九)删除topic

目前删除topic在默认情况下只是打上一个删除的标记，在重新启动kafka后才删除。如果需要立即删除，则需要在server.properties中配置：

delete.topic.enable=true，然后执行以下命令进行删除topic

bin/kafka-topics.sh \
--zookeeper node01:2181,node02:2181,node03:2181 \
--delete \
--topic test

关闭Kafka集群, 三套机同时执行以下命令

cd /export/servers/kafka_2.11-1.0.0
bin/kafka-server-stop.sh