KafKa核心组成
1、 Kafka生产过程分析
1.1、 写入方式
producer采用推(push)模式将消息发布到broker,每条消息都被追加(append)到分区(patition)中,属于顺序写磁盘(顺序写磁盘效率比随机写内存要高,保障kafka吞吐率)。
1.2 、分区(Partition)
消息发送时都被发送到一个topic,其本质就是一个目录,而topic是由一些Partition Logs(分区日志)组成,其组织结构如下图所示:
我们可以看到,每个Partition中的消息都是有序的,生产的消息被不断追加到Partition log上,其中的每一个消息都被赋予了一个唯一的offset值。
1)分区的原因
(1)方便在集群中扩展,每个Partition可以通过调整以适应它所在的机器,而一个topic又可以有多个Partition组成,因此整个集群就可以适应任意大小的数据了;
(2)可以提高并发,因为可以以Partition为单位读写了。
2)分区的原则
(1)指定了patition,则直接使用;
(2)未指定patition但指定key,通过对key的value进行hash出一个patition;
(3)patition和key都未指定,使用轮询选出一个patition。
DefaultPartitioner类
public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
int numPartitions = partitions.size();
if (keyBytes == null) {
int nextValue = nextValue(topic);
List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
if (availablePartitions.size() > 0) {
int part = Utils.toPositive(nextValue) % availablePartitions.size();
return availablePartitions.get(part).partition();
} else {
// no partitions are available, give a non-available partition
return Utils.toPositive(nextValue) % numPartitions;
}
} else {
// hash the keyBytes to choose a partition
return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
}
}
1.3、 副本(Replication)
同一个partition可能会有多个replication(对应 server.properties 配置中的 default.replication.factor=N)。没有replication的情况下,一旦broker 宕机,其上所有 patition 的数据都不可被消费,同时producer也不能再将数据存于其上的patition。引入replication之后,同一个partition可能会有多个replication,而这时需要在这些replication之间选出一个leader,producer和consumer只与这个leader交互,其它replication作为follower从leader 中复制数据。
1.4、 写入流程
producer写入消息流程如下(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 保存消息
2.1、 存储方式
物理上把topic分成一个或多个patition(对应 server.properties 中的num.partitions=3配置),每个patition物理上对应一个文件夹(该文件夹存储该patition的所有消息和索引文件),如下:
[root@hadoop105 logs]# ls
cleaner-offset-checkpoint controller.log.2020-01-14-23 controller.log.2020-01-17-06 recovery-point-offset-checkpoint server.log.2020-01-17-01
__consumer_offsets-11 controller.log.2020-01-15-00 controller.log.2020-01-17-07 replication-offset-checkpoint server.log.2020-01-17-02
__consumer_offsets-14 controller.log.2020-01-16-13 controller.log.2020-01-17-08 server.log server.log.2020-01-17-03
__consumer_offsets-17 controller.log.2020-01-16-14 controller.log.2020-01-17-09 server.log.2020-01-14-16 server.log.2020-01-17-04
__consumer_offsets-2 controller.log.2020-01-16-15 controller.log.2020-01-17-10 server.log.2020-01-14-23 server.log.2020-01-17-05
__consumer_offsets-20 controller.log.2020-01-16-16 controller.log.2020-01-17-11 server.log.2020-01-15-00 server.log.2020-01-17-06
__consumer_offsets-23 controller.log.2020-01-16-17 first-0 server.log.2020-01-15-20 server.log.2020-01-17-07
__consumer_offsets-26 controller.log.2020-01-16-18 kafka-authorizer.log server.log.2020-01-16-13 server.log.2020-01-17-08
__consumer_offsets-29 controller.log.2020-01-16-19 kafka-request.log server.log.2020-01-16-14 server.log.2020-01-17-09
__consumer_offsets-32 controller.log.2020-01-16-20 kafkaServer-gc.log.0.current server.log.2020-01-16-15 server.log.2020-01-17-10
__consumer_offsets-35 controller.log.2020-01-16-21 log-cleaner.log server.log.2020-01-16-16 server.log.2020-01-17-11
__consumer_offsets-38 controller.log.2020-01-16-22 log-cleaner.log.2020-01-14-16 server.log.2020-01-16-17 state-change.log
__consumer_offsets-41 controller.log.2020-01-16-23 log-cleaner.log.2020-01-14-23 server.log.2020-01-16-18 state-change.log.2020-01-14-16
__consumer_offsets-44 controller.log.2020-01-17-00 log-cleaner.log.2020-01-15-00 server.log.2020-01-16-19 state-change.log.2020-01-14-23
__consumer_offsets-47 controller.log.2020-01-17-01 log-cleaner.log.2020-01-16-13 server.log.2020-01-16-20 state-change.log.2020-01-15-00
__consumer_offsets-5 controller.log.2020-01-17-02 log-cleaner.log.2020-01-16-18 server.log.2020-01-16-21 state-change.log.2020-01-16-13
__consumer_offsets-8 controller.log.2020-01-17-03 log-cleaner.log.2020-01-16-19 server.log.2020-01-16-22 state-change.log.2020-01-16-18
controller.log controller.log.2020-01-17-04 log-start-offset-checkpoint server.log.2020-01-16-23 state-change.log.2020-01-16-19
controller.log.2020-01-14-16 controller.log.2020-01-17-05 meta.properties server.log.2020-01-17-00 state-change.log.2020-01-16-21
[root@hadoop105 logs]# cd first-0/
[root@hadoop105 first-0]# ll
total 8
-rw-r--r--. 1 root root 10485760 Jan 16 22:12 00000000000000000000.index
-rw-r--r--. 1 root root 150 Jan 16 22:43 00000000000000000000.log
-rw-r--r--. 1 root root 10485756 Jan 16 22:12 00000000000000000000.timeindex
-rw-r--r--. 1 root root 8 Jan 16 22:30 leader-epoch-checkpoint
[root@hadoop105 first-0]#
在hadoop105机器,启动一个生产者,执行命令:
[root@hadoop105 kafka]# bin/kafka-console-producer.sh --broker-list hadoop105:9092 --topic first
>HelloWorld
>HelloKafKa
>
若我们在hadoop106机器上查看logs文件目录下的first-0文件的00000000000000000000.log 文件,会发生乱码
[root@hadoop106 logs]# ls
cleaner-offset-checkpoint __consumer_offsets-45 kafka-request.log server.log.2020-01-15-20 server.log.2020-01-17-05
__consumer_offsets-0 __consumer_offsets-48 kafkaServer-gc.log.0.current server.log.2020-01-16-13 server.log.2020-01-17-06
__consumer_offsets-12 __consumer_offsets-6 log-cleaner.log server.log.2020-01-16-17 server.log.2020-01-17-07
__consumer_offsets-15 __consumer_offsets-9 log-cleaner.log.2020-01-14-16 server.log.2020-01-16-18 server.log.2020-01-17-08
__consumer_offsets-18 controller.log log-cleaner.log.2020-01-14-23 server.log.2020-01-16-19 server.log.2020-01-17-09
__consumer_offsets-21 controller.log.2020-01-14-16 log-cleaner.log.2020-01-15-20 server.log.2020-01-16-20 server.log.2020-01-17-10
__consumer_offsets-24 controller.log.2020-01-14-23 log-cleaner.log.2020-01-16-19 server.log.2020-01-16-21 server.log.2020-01-17-11
__consumer_offsets-27 controller.log.2020-01-15-20 log-start-offset-checkpoint server.log.2020-01-16-22 state-change.log
__consumer_offsets-3 controller.log.2020-01-16-19 meta.properties server.log.2020-01-16-23 state-change.log.2020-01-14-16
__consumer_offsets-30 controller.log.2020-01-16-20 recovery-point-offset-checkpoint server.log.2020-01-17-00 state-change.log.2020-01-14-23
__consumer_offsets-33 controller.log.2020-01-16-21 replication-offset-checkpoint server.log.2020-01-17-01 state-change.log.2020-01-15-20
__consumer_offsets-36 first-0 server.log server.log.2020-01-17-02 state-change.log.2020-01-16-19
__consumer_offsets-39 first-1 server.log.2020-01-14-16 server.log.2020-01-17-03 state-change.log.2020-01-16-21
__consumer_offsets-42 kafka-authorizer.log server.log.2020-01-14-23 server.log.2020-01-17-04
[root@hadoop106 logs]# cd first-0/
[root@hadoop106 first-0]# ls
00000000000000000000.index 00000000000000000000.log 00000000000000000000.timeindex leader-epoch-checkpoint
[root@hadoop106 first-0]# cat 00000000000000000000.log
C¦lo°z¦lÿÿÿÿÿÿÿÿÿÿÿÿÿÿ"hello world;# ڵo°¬o°¬ÿÿÿÿÿÿÿÿÿÿÿÿÿÿHe!B
àPo³Bo³Bÿÿÿÿÿÿÿÿÿÿÿÿÿÿ HelloKafKa[root@hadoop106 first-0]#
这个乱码,主要文件的序列化,文件的数据主要存储在00000000000000000000.log 文件上
2.2、 存储策略
无论消息是否被消费,kafka都会保留所有消息。有两种策略可以删除旧数据:
(1)基于时间:log.retention.hours=168
(2)基于大小:log.retention.bytes=1073741824
需要注意的是,因为Kafka读取特定消息的时间复杂度为O(1),即与文件大小无关,所以这里删除过期文件与提高 Kafka 性能无关。
2.3、 Zookeeper存储结构
注意:producer不在zk中注册,消费者在zk中注册。
我们可以进入zookeeper的客户端,查看一下信息:
[root@hadoop107 bin]# zkCli.sh
[zk: localhost:2181(CONNECTED) 0] ls /
[cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, latest_producer_id_block, config]
[zk: localhost:2181(CONNECTED) 1]
[zk: localhost:2181(CONNECTED) 2] ls /brokers
[ids, topics, seqid]
[zk: localhost:2181(CONNECTED) 3] ls /brokers/ids
[0, 1, 2]
[zk: localhost:2181(CONNECTED) 4] ls /brokers/ids/0
[]
[zk: localhost:2181(CONNECTED) 5] get /brokers/ids/0
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://hadoop105:9092"],"jmx_port":-1,"host":"hadoop105","timestamp":"1579212230998","port":9092,"version":4}
cZxid = 0x500000008
ctime = Thu Jan 16 22:03:50 GMT 2020
mZxid = 0x500000008
mtime = Thu Jan 16 22:03:50 GMT 2020
pZxid = 0x500000008
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x36fb06104bc0000
dataLength = 188
numChildren = 0
[zk: localhost:2181(CONNECTED) 7] ls /brokers
[ids, topics, seqid]
[zk: localhost:2181(CONNECTED) 8] ls /brokers/topics
[first, __consumer_offsets]
[zk: localhost:2181(CONNECTED) 9] ls /brokers/topics/first
[partitions]
[zk: localhost:2181(CONNECTED) 10] ls /brokers/topics/first/partitions
[0, 1]
[zk: localhost:2181(CONNECTED) 11] ls /brokers/topics/first/partitions/0
[state]
[zk: localhost:2181(CONNECTED) 12] ls /brokers/topics/first/partitions/0/state
[]
[zk: localhost:2181(CONNECTED) 13]
##查看分区状态,使用“get”
[zk: localhost:2181(CONNECTED) 13] get /brokers/topics/first/partitions/0/state
{"controller_epoch":3,"leader":0,"version":1,"leader_epoch":0,"isr":[0,1]}
cZxid = 0x50000001f
ctime = Thu Jan 16 22:12:46 GMT 2020
mZxid = 0x50000001f
mtime = Thu Jan 16 22:12:46 GMT 2020
pZxid = 0x50000001f
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 74
numChildren = 0
#消费者
[zk: localhost:2181(CONNECTED) 15] ls /consumers
[]
[zk: localhost:2181(CONNECTED) 16] get /consumers
null
cZxid = 0x4
ctime = Tue Jan 14 23:17:57 GMT 2020
mZxid = 0x4
mtime = Tue Jan 14 23:17:57 GMT 2020
pZxid = 0x50000006a
cversion = 4
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 0
[zk: localhost:2181(CONNECTED) 18]
3、 Kafka消费过程分析
kafka提供了两套consumer API:高级Consumer API和低级Consumer API。
3.1 、高级API
(1)高级API优点
高级API 写起来简单
不需要自行去管理offset,系统通过zookeeper自行管理。
不需要管理分区,副本等情况,.系统自动管理。
消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据(默认设置1分钟更新一下zookeeper中存的offset)
可以使用group来区分对同一个topic 的不同程序访问分离开来(不同的group记录不同的offset,这样不同程序读取同一个topic才不会因为offset互相影响)
(2)高级API缺点
不能自行控制offset(对于某些特殊需求来说)
不能细化控制如分区、副本、zk等
3.2、 低级API
(1)低级 API 优点
能够让开发者自己控制offset,想从哪里读取就从哪里读取。
自行控制连接分区,对分区自定义进行负载均衡
对zookeeper的依赖性降低(如:offset不一定非要靠zk存储,自行存储offset即可,比如存在文件或者内存中)
(2)低级API缺点
太过复杂,需要自行控制offset,连接哪个分区,找到分区leader 等。
3.3、 消费者组
消费者是以consumer
group消费者组的方式工作,由一个或者多个消费者组成一个组,共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取,但是多个group可以同时消费这个partition。在图中,有一个由三个消费者组成的group,有一个消费者读取主题中的两个分区,另外两个分别读取一个分区。某个消费者读取某个分区,也可以叫做某个消费者是某个分区的拥有者。
在这种情况下,消费者可以通过水平扩展的方式同时读取大量的消息。另外,如果一个消费者失败了,那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。
3.4、 消费方式
consumer采用pull(拉)模式从broker中读取数据。
push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成consumer来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。
对于Kafka而言,pull模式更合适,它可简化broker的设计,consumer可自主控制消费消息的速率,同时consumer可以自己控制消费方式——即可批量消费也可逐条消费,同时还能选择不同的提交方式从而实现不同的传输语义。
pull模式不足之处是,如果kafka没有数据,消费者可能会陷入循环中,一直等待数据到达。为了避免这种情况,我们在我们的拉请求中有参数,允许消费者请求在等待数据到达的“长轮询”中进行阻塞(并且可选地等待到给定的字节数,以确保大的传输大小)。
3.5、 消费者组案例
1)需求:
测试同一个消费者组中的消费者,同一时刻只能有一个消费者消费。
2)案例实操
(1)在hadoop105、hadoop106上修改/usr/local/hadoop/module/kafka/config/consumer.properties配置文件中的group.id属性为任意组名。
[root@hadoop105 config]# vim consumer.properties
group.id=atguigu
(2)在hadoop107上启动生产者(发送)
hadoop107机器:
[root@hadoop107 kafka]# bin/kafka-console-producer.sh --broker-list hadoop105:9092 --topic first
>Hello
>
(3)在hadoop105上启动消费者(接收)
hadoop105机器:
[root@hadoop105 kafka]# bin/kafka-console-consumer.sh --zookeeper hadoop105:2181 --topic first config/consumer.properties
Using the ConsoleConsumer with old consumer is deprecated and will be removed in a future major release. Consider using the new consumer by passing [bootstrap-server] instead of [zookeeper].
Hello
同一时刻只有一个消费者接收到消息。