Kafka学习笔记，面试准备

Kafka

参考网址：https://blog.csdn.net/u013256816/article/details/89369160

                 https://www.cnblogs.com/qingyunzong/p/9004703.html

                 https://www.jianshu.com/p/1f02328a4f2e

就在前些日子，我面试了北京的一家公司，其中他们就问到了Kafka的问题，在这之前我并未对这个组件十分重视，而且是只会使用。在那次面试之后又补了很多关于Kafka原理相关的知识
问题是这样的，你们的项目中为什么使用的消息中间件的Kafka，而没有使用其他的MQ。下面会介绍到Kafka的优点，若出现此类问题，请基于优点回答。

Kafka是一个基于发布/订阅模式的消息中间件。它是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等。

Kafka用scala语言编写。Kafka不受语言限制。

Kafka多用于大数据开发的消息中间件，Java开发会采用其他的消息中间件，比如RMQ

只要公司里在用spark，90%的情况是需要和Kafka对接的。

后续的spark学习中的与Kafka对接的代码也是重点需要掌握的内容

Kafka的优点特点

高吞吐量，低延迟。Kafka可以每秒处理几十万条消息，但是它的延迟只有几毫秒

可扩展性。Kafka支持热扩展。

持久性，可靠性。消息在被消费之后，并不会立刻消失。Kafka中的消息会落地保留在本地，会有一个本地的停留时间。默认168小时（一周）。或者log文件的大小达到1073741824字节的时候也会将Kafka的本地文件删除。

容错性，高可用：允许集群中节点失败（副本数为N的情况下允许N-1个节点失败）

高并发：支持无数个客户端同时读写。并且支持异步传输

避免强依赖性，可以避免被迫访问其他系统，等待其相应

开发语言通用性，支持大部分开发语言

使用场景

日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

消息系统：解耦和生产者和消费者、缓存消息等。

这个是我的项目中主要讲解与使用的功能

生产者产产生日志列队

将操作信息传给Kafka

消费者从Kafka中拿去日志操作，根据实际业务逻辑处理（数据分析器hive，mysql）

Topic 按照topic分类维护消息

Producer 生产者 发布消息到topic进程

Consumer 消费者 订阅topic并处理topic中的消息

用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

流式处理：比如spark streaming和storm

事件源

安装Kafka

下载页面：http://kafka.apache.org/downloads

上传kafka的安装包到linux系统

解压

创建软连接

创建一个logs目录 是存放日志的

cd
conf

vim server.properties

broker.id=0
broker全局的编号，不能重复的

delete.topic.enable=true 启动删除topic功能

num.network.threads=3 处理请求的线程数

num.io.threads=8 进行磁盘io处理的线程数

socket.send.buffer.bytes=102400 发送消息的缓冲区大小

socket.receive.buffer.bytes=102400 接收消息的缓冲区大小

socket.request.max.bytes=104857600 发送请求的套接字大小

log.dirs=/home/hadoop/software/kafka/logs 日志的存放位置

num.partitions=1 topic在当前的broker的分区数

num.recovery.threads.per.data.dir=1 清理恢复数据的线程数量

log.retention.hours=168 日志文件的保留时间

zk集群

zookeeper.connect=hadoop101:2181,hadoop102:2181,hadoop103:2181

修改环境变量：

#kafka环境变量

export KAFKA_HOME=/home/hadoop/software/kafka

export PATH=$PATH:$KAFKA_HOME/bin

分发到其他机器，并且修改环境变量

修改broker.id的值

常用相关词汇

Broker

Kafka 集群包含一个或多个服务器，服务器节点称为broker。

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

类似于数据库的表名

Partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

Producer

生产者，数据的产生者、发布者。该角色将消息发送到Kafka的topic中。

节点在接手到生产者发送的消息后，节点会将该消息追加到所属topic的segment文件中。

Consumer

消费者从broker中读取数据

Consumer Group

消费者组。每个consumer都属于一个consumer group。

Leader

每个partition都会有多个副本，但是只有其中一个是作为leader，接收来自producer的数据。

Follower

leader的跟随者，follower的数量位副本数-1。每个follower都会从自己的leader上拉取数据，并与leader同步。如果leader失效，则从follower中选举一个leader（通过zookeeper）。若follower挂掉、卡住或者同步太慢，leader会把follower从ISR列表中删除，新建follower。

常用操作

a)
开启Kafka脚本kafka-server-start.sh -daemon server.properties 红色标注部分为可选项，选择是否为后台运行

b)
创建主题kafka-topics.sh
–create --zookeeper localhost:2181 --replication-factor 1 --partitions 1
–topic test

kafka-topics.sh主题脚本

–create 创建指令

–topic test 创建的是topic名为test

–zookeeper指定主题创建在zookeeper上 localhost:2181 指定一个zookeeper的机器IP

–replication-factor
1 指定副本数为1

–partitions 1
指定分区数为1

c)创建生产者kafka-console-producer.sh
–broker-list localhost:9092 --topic test

kafka-console-producer.sh 创建生产者控制台脚本

–broker-list
localhost:9092 指定partition需要分配到哪些节点，目标节点的IP与端口号，这里可以填写多个ip和端口号

–topic
test指定被消费的topic

d)创建消费者kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup
–consumer-property client.id=consumer-1
–topic test

kafka-console-consumer.sh 创建消费者控制台脚本

–bootstrap-server localhost:9092 指定Consumer需要分配到哪些节点，目标节点的IP与端口号，同理，可以指定多个ip和端口号

–consumer-property group.id=testGroup将用户定义属性以key=value形式传递给使用者（赋值）group.id=testGroup指定消费者所属组的ID 为testGroup

–consumer-property client.id=consumer-1同理 将客户端的id设置为consumer-1

–topic test指定被消费的topic

关于偏移量

current-offsets，偏移量，针对消费者来说，他就是代表消费到的位置

每个组的偏移量是不同的！

假定生有一个生产者向3个分区依次输入1-9

假如数据会按照以下格式进入分区，实际数据不会这么有序，这里用的纯数字数据，是可以达到下面的效果的，分区是用的默认的hashpartition方法，所以数据内容复杂的情况分区并没有什么规律可循，这里为了方便举例所以用了纯数字

分区1：147

分区2：258

分区3：369

若消费者只有一个且是与生产者同时运行的，那么他会及时的读取到消息并消费，消费顺序就是123456789。

若消费者滞后到生产者执行完毕再运行，他将会读取完一个分区再读取下一个分区，消费的顺序可能为147 258 369。实际可能会因为读取分区的顺序不一样，略微会有所不同（比如可能读取顺序是 分区3，分区2，分区1，这样就会得到369，258，147）。这里强调的是他会读完一个分区再读下一个分区。

假如说存在同组用户有多个，且用户数量等于分区数时，同组的每一个消费只消费一个分区的数据。生产者数据写入各个分区，而且同组用户一个用户负责一个分区，这就是为什么会出现同组用户轮巡执行消费的现象。

若同组用户数量大于分区数（一般会避免这种情况），那么仍然是一个用户负责一个分区，多余的消费者用户将会闲置。比如，有两个分区，同组用户为3，那么会出现其中两个用户一直轮换的消费，另一个用户处于完全挂机的状态。实际开发中这样是非常浪费资源的。

正是由于引入了偏移量的概念，即使是两个消费者操作一个分区，也不会读取相同的数据。这就是我们所说的一个消息只能被一个组消费一次的原因。

我们尽量要设置一个组的用户小于等于分区数

Kafka架构

生产者会将数据发送给每个partition的leader。每个partition的follower都会远程从leader上拉取数据。消费者也只会从leader上拿去数据。follower的意义是leader宕机时，他们会在条件满足的情况下变成leader。

选举和数据的同步过程都由zookeeper的一致性服务进行监视的。

Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高

写流程

1. producer 先从
   zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader

2. producer 将消息发送给该
   leader

3. leader 将消息写入本地
   log

4. followers 从
   leader 远程拉取消息，写入本地 log 后 leader
   发送确认报文（ACK）

5. leader 收到所有所属followr的 ACK 后，向 producer 发送
   ACK

Kafka中的分区leader选举

同一个分区，不同的副本，会存在一个leader和多个follower。这个过程也是由zookeeper的一致服务完成的。

所有Follower都在ZooKeeper上设置一个Watch，一旦Leader宕机，其对应的znode（zookeeper节点）会自动删除，此时所有Follower都尝试创建Leader节点，而创建成功者（ZooKeeper保证只有一个能创建成功）即是新的Leader。

Kafka-HA的ZooKeeper节点结构

admin临时目录，特定操作时产生，操作结束之后会删除。

config配置文件目录。

broker topic注册信息目录。