大数据篇：Kafka

大数据篇：Kafka

kafka.apache.org

Kafka 是什么?

Kafka是一种高吞吐量的分布式发布、订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

如果没有Kafka

大数据领域的每秒数百万以上的消息，消息的持久化无法处理；

传统领域的发短信、邮件的等异步操作，削峰处理等等。（当然也可以使用RabbitMQ、ActiveMQ、RocketMQ等）

1 两种消息处理模式

2 Kafka架构

1. Producer ：消息生产者，kafka broker发消息的客户端。

2. Consumer ：消息消费者，kafka broker接收消息的客户端

3. Topic ：一个主题，用于说明生产消费使用的是什么主题，可以理解为一个队列。(对数据进行分类)

4. Consumer Group （CG）：kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。(如上图TopicA发送给消费者组的消息，由ConsumerA接收了，那么ConsumerB就不能接收了，这时就实现了单播)(如上图假设，3个consumer各为一个消费者组，TopicA由3个组共同接收了，这时就实现了广播)(理论上，Topic的分区数对应消费者组中消费者数量性能最优)

5. Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

6. Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。（kafka只能读取Leader的partition中的信息）

7. Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然第一个offset就是00000000000.kafka

8. zookeeper：用来保存kafka集群的配置等信息

3 监控安装

3.1 Kafkatool

此软件用来查看kafka生产者数据等信息，下载安装即可。

• http://www.kafkatool.com/download.html

• 百度网盘地址：https://pan.baidu.com/s/1N8BCXXgVydrDvJYXRSYxdQ 提取码：calp

3.2 CMAK

CMAK（以前称为Kafka Manager）是用于管理Kafka集群的工具，主要用来观察消费者等信息。3.0.x以上需要java11以上，zookeeper3.5.x以上才可以运行

• https://github.com/yahoo/CMAK

• 百度网盘地址：https://pan.baidu.com/s/1QJeRs36bbfm9xWTPEEYKfg 提取码：la2m

1. 上传文件包解压

mkdir /usr/local/src/CMAK
cd /usr/local/src/CMAK
unzip cmak-3.0.0.4.zip
cd cmak-3.0.0.4

2. 修改配置

vim conf/application.conf

zk集群，注意这里配置的需要和kafka配置的对应，否则web会找不到消费者组，如果找不到把IP换成hostname，或者把hostname换成IP。

老版本

kafka-manager.zkhosts="192.168.xx.xx:2181,192.168.xx.xx:2181,192.168.xx.xx:2181"

新版本

cmak.zkhosts="192.168.xx.xx:2181,192.168.xx.xx:2181,192.168.xx.xx:2181"

3. 启动

cmak 默认的端口是8080，可通过 -Dhttp.port，指定端口; -Dconfig.file=conf/application.conf指定配置文件:

nohup bin/cmak -Dconfig.file=conf/application.conf -Dhttp.port=8080

4 命令操作

4.1 创建 topic

#创建top-test主题，2个分区，2个副本
kafka-topics --create --zookeeper cdh01.cm:2181,cdh02.cm:2181,cdh03.cm:2181 --topic top-test --partitions 2 --replication-factor 2

4.2 查看topic

kafka-topics --list --zookeeper cdh01.cm:2181,cdh02.cm:2181,cdh03.cm:2181

4.3 删除topic

kafka-topics --delete --zookeeper cdh01.cm:2181,cdh02.cm:2181,cdh03.cm:2181 --topic top-test

4.4 查看topic详情

kafka-topics --describe --zookeeper cdh01.cm:2181,cdh02.cm:2181,cdh03.cm:2181 --topic top-test

4.5 生产者-消费者

#生产者
kafka-console-producer --topic top-test --broker-list cdh01.cm:9092,cdh02.cm:9092,cdh03.cm:9092
#消费者(--from-beginning 从头开始读取)
kafka-console-consumer --topic top-test --bootstrap-server cdh01.cm:9092,cdh02.cm:9092,cdh03.cm:9092  --from-beginning --group g1

• 首先在生产者端输入多条数据，我这里输入aa->ff，效果如下

5 Kafka工作流程

kafka每个分区的offset都是从0开始的，保证了区内有序，不能保证全局有序；

producer不在zk中注册，消费者在zk中注册。

topic是逻辑上的概念，而partition是物理上的概念，每个partition对应一个log文件，该log文件中储存的就是生产的数据。生产者生产的数据会被不断的追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。如下图：

5.1 生产消息过程

1步解释：producer先从zookeeper的 "/brokers/.../state"节点找到该topic对应partition的leader;

通过4-6步保证数据可靠性，kafka选择了必须全部ack发送成功才完成同步。

• 分区的原因

  • 方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
  • 可以提高并发，因为可以以Partition为单位读写了。

• 分区原则

  • 指定了patition，则直接使用；

  • 未指定patition但指定key，通过对key的value进行hash出一个patition

  • patition和key都未指定，使用轮询选出一个patition。

5.2 消费消息过程

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

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

5.3 保存消息

由于生产者生产的消息会不断的追加到log文件末尾，为防止log文件过大导致的数据定位效率低问题，Kafka采取分片和索引机制，将每个patition分为多个segment。

每个segment对应2个文件-->".index和.log"文件。这些文件位于一个patition文件夹下，其patition文件夹命名规则为：topic名称-分区号。

".index和.log"文件以当前segment的第一条消息的offset命名，如下：

00000000000000000000.index

00000000000000000000.log

00000000000000135489.index

00000000000000135489.log

00000000000000268531.index

00000000000000268531.log

下面为".index和.log"文件结构示意图:

6 Kafka压测

6.1 Kafka Producer 压力测试

• record-size 是一条信息有多大，单位是字节。
• num-records 是总共发送多少条信息。
• throughput 是每秒多少条信息，设成-1，表示不限流，可测出生产者最大吞吐量。

./kafka-producer-perf-test --topic test --record-size 100 --num-records 100000 --throughput -1 --producer-props bootstrap.servers=cdh01.cm:9092,cdh02.cm:9092,cdh03.cm:9092

100000 records sent, 95877.277085 records/sec (9.14 MB/sec),

187.68 ms avg latency, 424.00 ms max latency, 155 ms 50th, 411 ms

95th, 423 ms 99th, 424 ms 99.9th

参数解析：一共写入 10w 条消息，吞吐量为 9.14 MB/sec，每次写入的平均延迟

为 187.68 毫秒，最大的延迟为 424.00 毫秒。

6.2 Kafka Consumer 压力测试

• zookeeper 指定 zookeeper 的链接信息

• topic 指定 topic 的名称

• fetch-size 指定每次 fetch 的数据的大小

• messages 总共要消费的消息个数

./kafka-consumer-perf-test.sh --zookeeper cdh01.cm:2181 --topic test --fetch-size 10000 --messages 10000000 --threads 1

start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec

2019-02-19 20:29:07:566, 2019-02-19 20:29:12:170, 9.5368, 2.0714, 100010, 21722.4153

开始测试时间，测试结束数据，共消费数据 9.5368MB，吞吐量 2.0714MB/s，共消费100010 条，平均每秒消费 21722.4153 条。

6.3 Kafka 机器数量计算

Kafka 机器数量（经验公式）=2（峰值生产速度副本数/100）+1

先拿到峰值生产速度，再根据设定的副本数，就能预估出需要部署 Kafka 的数量。

比如我们的峰值生产速度是 50M/s。副本数为 2。

Kafka 机器数量=2（502/100）+ 1=3 台