1.Kafka工作流程
Kafka中的消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。
topic是逻辑上的概念,而partition是物理上的概念,每个partiyion对应于一个log文件,该log文件存储的是生产者生产的消息。Producer生产的数据会被不断的追加到该log文件末尾,切每条数据都有自己的offset。消费者组中的每个消费者,都会实时记录自己消费到哪个offset,以便在出错恢复中,从上次的位置继续消费。
为防止log文件过大导致数据定位效率低下,每个log文件不会一直追加数据到文件末尾。kafka采用了分片和索引机制,将每个partition分为多个segment(分片)。每个segment对应两个文件:XXX.index
和XXX.log
文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号
。例如:demo这个topic有三个分区,则对应的文件夹为first-0,first-1,first-2
00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log
index和log文件以当前segment的第一条消息的offset命名,下图为index文件和log文件的结构示意图:
"index"文件存储大量的索引信息,"log"文件存储着大量的数据,索引文件中的元数据指向对应数据文件中message的物理偏移地址。
如何查找到offset=3?
通过offset通过二分查找法确定在哪个索引文件,找到3得到该数据的起始偏移量(索引文件中存储的是每个消息的起始偏移量和消息大小)就能得到这个消息的起始偏移量和结束偏移量。
2.Kafka生产者
分区策略
-
分区的原因
方便在集群中扩展,每个partition可以通过调整以适应它所在的机器,而一个topic又可以通过有多个Partition组成,因此整个集群就可以适应任意大小的数据了。
提高并发,消费者可以以Partition为单位读写
-
分区的原则
我们需要将producer发送的数据封装成一个
ProducerRecord
对象。public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value, Iterable<Header> headers) public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value) public ProducerRecord(String topic, Integer partition, K key, V value, Iterable<Header> headers) public ProducerRecord(String topic, Integer partition, K key, V value) public ProducerRecord(String topic, K key, V value)
(1) 指明partiton的情况下,直接将指明的值作为partition的值
(2) 没有指明partition的值但有key的情况下,将key的hash值与topic的partition数进行取余得到partition值(key的哈希分区)
(3) 既没有partition值又没有key值的情况下,第一次调用时随机生成一个整数(后面每次调用在这个个整数上自增),将这个值与topic可用的partition总数取余得到partition总数取余得到partition值,也就是round-robin算法,例如三个分区第一次得到的分区顺序为2,0,1 呢么以后每次都是2,0,1
数据的可靠性保证
为了保证producer发送的数据,能可靠的发送到指定的topic,topic的每个partition收到producer发送的数据后,都需要向producer发送ack(acknowledgement 确认收到),如果producer收到ack,就会进行下一轮的发送,否则重新发送数据。
-
副本数据同步策略
方案 优点 缺点 半数以上完成同步,就发送ack 延迟低 选举新的leader时,容忍n台节点的故障,就需要2n+1个副本 全部完成同步,才发送ack 选举新的leader时,容忍n台节点的故障,就需要n+1个副本 延迟高 Kafka选择了第二种方案,原因如下:
1.同样为了容忍n台节点的故障,第一种方案需要2n+1个副本,而第二种方案只需要n+1个副本,而Kafka的每个分区都有大量的数据,第一种方案会造成大量数据的冗余。
2.虽然第二种方案的网络延迟会比较高,但网络延迟对Kafka的影响较小。
-
ISR
采用第二种方案之后,设想以下情景:leader收到数据,所有follower都开始同步数据,但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要一直等下去,直到它完成同步,才能发送ack。这个问题怎么解决呢?
Leader维护了一个动态的in-sync replica set (ISR),意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后,leader就会给follower发送ack。如果follower长时间未向leader同步数据,则该follower将被踢出ISR,该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后,就会从ISR中选举新的leader。
-
ack应答机制
对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失,所以没必要等ISR中的follower全部接收成功。所以Kafka为用户提供了三种可靠性级别,用户根据对可靠性和延迟的要求进行权衡,选择以下的配置。
acks参数配置:
acks:
0:producer不等待broker的ack,这一操作提供了一个最低的延迟,broker一接收到还没有写入磁盘就已经返回,当broker故障时有可能丢失数据;
1:producer等待broker的ack,partition的leader落盘成功后返回ack,如果在follower同步成功之前leader故障,那么将会丢失数据;
-1(all):producer等待broker的ack,partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后,broker发送ack之前,leader发生故障,那么会造成数据重复。
-
故障处理细节
在ISR同步中有两个词语需要知道:
LEO:每个副本的最后一个offset HW:所有副本中最小的LEO
(1) follower 故障
follower发生故障后会被临时剔出ISR,待该follower恢复后,follower会将读取本地磁盘记录的上次
的HW,并将log文件高于HW的部分截取掉,从HW开始向leader进行同步。等该follower的LEO大于等于该partition的HW
,即follpwer追上leader之后,就可以重新加入ISR了。
(2) leader 故障
leader发生故障之后,会从ISR中选举出一个新的leader,之后,为保证多个副本之间的数据一致性,其余的follower会先将各自的log文件高于HW的部分截掉,然后从新的leader同步数据
!!!!注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。在一定情况下还是会发生数据丢失或者重复
Exactly Once 语义
Kafka提供了生产者和消费者之间的担保语义:
- AtLeast Once(至少一次)—— 消息绝不会丢失,但有可能重复,将ACK级别设置为all
- AtMost Once(最多一次)—— 消息可能会丢失,但绝不会重发,将ACK级别设置为0
- Exactly once(精准一次)—— 每个消息传递一次且只有一次,开启幂等性
在0.11版本之前,kafka只能保证数据不丢失,在下游消费者对数据做全局去重,对于多个下游应用的情况,每个都需要单独做全局去重,对性能造成了很大的影响。
但是在0.11版本之后,加入了幂等性,所谓的幂等性就是指Producer不论向Server发送多少次重复数据,Server端都只会持久化一条数据,幂等性结合AtLeast Once语义
就构成了Exactly Once语义
,即:
AtLEast Once +幂等性 = Exactly Once
开启幂等性,只需要enabled.idompotence=true
即可,Kafka的幂等性实现其实就是把下游的数据去重放在了broker上,开启幂等性的Producer在初始化的时候会被分配一个PID,发生同一Partition的消息会附带Sequence Number(序列号),而Broker端会对<PID,Partition,SeqNumber>
做缓存,这里的SeqNumber不是Offset,当具有相同主键的消息提交时,Broker只会持久化一条。从0.11开始生产者支持使用类似事务的语义将消息发送到多个topic分区的能力:即所有消息都被成功写入或者没有。
注意: Producer重启PID就会变化,同时不同的partition也具有不同的主键,所以幂等性无法保证跨分区跨会话的Exactly Once
3. Kafka消费者
消费方式
consumer采用pull(拉)模式从broker中读取数据。push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成consumer的消费速度赶不上broker的发送速度,从而会导致consumer拒绝服务以及网络拥塞。而pull模式则可以根据consumer自身的消费能力以适当的消费速率消费消息。
pull模式不足之处:kafka无消息时,消费者陷入循环,一直返回空数据。针对这一点,kafka的消费者在消费数据时会传入一个时长参数timeout
,如果当前没有数据可供消费,consumer会等待一段时间之后再返回,这段时长就是timeout。
分区分配策略
一个consumer group 中有多个consumer,一个topic可以有多个partition,所以必然会有分区分配问题。一个topic可以被多个消费者组消费,一个消费者组可以消费多个topic,但是每个分区只能被同一个消费者组中的一个消费者消费。
Kafka有两种分配策略,一是roundrobin(轮询),一是range(范围)。
-
Roundrobin(轮询策略,按照组划分)
假如有三个消费者组,一个topic,七个分区:
最后结果为:
这就是轮询,但是这只是一个topic主题,如果有多个topic主题订阅并使用轮询。就会出现问题。当一个consumer group 消费多个不同的主题的时候,consumer group 会将这些topic以及分区 看成一个整体,然后通过哈希值做排序,然后在进行轮询。
所以,如果有两个主题,四个分区,一个消费者组,两个消费者,就会出现问题了
所以,使用轮询的前提是消费者组在订阅同一个主题的分区!!!!
轮询可以尽量保证分配的分区均衡,最大差别为1
-
Range(范围策略,按照主题划分)
该策略是kafka默认的分区策略,按照单个主题分配分区,按照范围分配分区。
例如,一个topic,7个分区,3个消费者,一个消费者组
分配完成后:
当有多个topic的时候,就会出现这种情况:
当消费者组内的消费者个数发生变化的时候,就会触发消费者的重新分配分区!!!
offset的维护
Kafka在0.9版本之前,consumer默认将offset保存在Zookeeper中,从0.9版本开始,consumer默认将offset保存在Kafka一个内置的topic中,该topic为__consumer_offsets
实例:
创建一个主题,两个副本,两个分区
bin/kafka-topics.sh --create --zookeeper master:2181 --topic bigdata --partitions 2 --replication-factor 2
向bigdata生产消息,同时打开一个消费者窗口
bin/kafka-console-consumer.sh --zookeeper master:2181 --topic bigdata --from-beginning
这里必须用zookeeper
才会把offset保存在zookeeper中。
然后我们去zookeeper查看
[zk: localhost:2181(CONNECTED) 0] ls / [cluster, controller_epoch, controller, brokers, zookeeper, kafka-manager, admin, isr_change_notification, consumers, latest_producer_id_block, config]
这里面除了zookeeper选项之外其他都是kafka的
controller:
指的是和zookeeper交互的broker。谁先和zookeeper建立连接,谁就是conrtoller
[zk: localhost:2181(CONNECTED) 3] get /controller
{"version":1,"brokerid":0,"timestamp":"1573653004493"}
cZxid = 0x288
ctime = Wed Nov 13 21:50:04 CST 2019
mZxid = 0x288
mtime = Wed Nov 13 21:50:04 CST 2019
pZxid = 0x288
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x16e6506ad240000
dataLength = 54
numChildren = 0
[zk: localhost:2181(CONNECTED) 4]
可以看到brokerId是0
brokers:
这里存的都是broker的信息
[zk: localhost:2181(CONNECTED) 4] ls /brokers
[ids, topics, seqid]
[zk: localhost:2181(CONNECTED) 5] ls /brokers/ids
[0, 1, 2]
[zk: localhost:2181(CONNECTED) 6]
config:
kafka的一些配置
consumers:
所有的消费者(使用–zookeeper才会显示,–bootstrap-server不显示)
[zk: localhost:2181(CONNECTED) 13] get /consumers/console-consumer-75598/offsets/bigdata/0
1
cZxid = 0x322
ctime = Wed Nov 13 22:35:31 CST 2019
mZxid = 0x326
mtime = Wed Nov 13 22:36:31 CST 2019
pZxid = 0x322
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 1
numChildren = 0
[zk: localhost:2181(CONNECTED) 14]
呢个1
就是存储的offset ,这是bigdata的分区0,他还有分区1,如果你继续生产,继续消费,就会让这两个分区的offset轮询记录
所以保存在Zookeeper采用的是消费者组_Topic_分区
.
这是保存在zookeeper中的形式,呢么看看offset保存在kafka的例子。
消费记录保存在Kafka本地:
Kafka 0.9版本之前,consumer默认将offset保存在Zookeeper中,从0.9版本开始,consumer默认将offset保存在Kafka一个内置的topic中,该topic为__consumer_offsets。
如果想获取kafka内置主题消息需要配置文件 consumer.properties :
exclude.internal.topics=false
读取__consumer_offsets主题的内容
这里使用zookeeper保存offset,是为了防止该消费者消进程即作为消费者有作为生产者,即自己生产自己消费。
运行命令:
./bin/kafka-console-consumer.sh --topic __consumer_offsets --zookeeper master:2181 --formatter "kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter" --consumer.config config/consumer.properties --from-beginning
运行截图:
如果kafka有消费者进程连接kafka。呢么这里的日志就会每隔(1秒,可设置)打印一次,因为消费者的offset会每隔一秒提交一次
[console-consumer-88458,bigdata,0]::[OffsetMetadata[2,NO_METADATA],CommitTime 1576308184247,ExpirationTime 1576394584247] [console-consumer-88458,bigdata,1]::[OffsetMetadata[1,NO_METADATA],CommitTime 1576308184247,ExpirationTime 1576394584247]
这里注意一下,这种数据其实也是K-V形式,K表示的是消费者组-主题-分区,V表示的是offset的消费记录。
这就会出现当在同一消费者组中增加消费者,当该消费者分到了一个分区,该消费者会得到该分区的offset会根据以前的消费记录接着消费,而不会重新消费。
4.Kafka 高效读写数据
1)顺序写磁盘 Kafka 的 producer 生产数据,要写入到 log 文件中,写的过程是一直追加到文件末端,
为顺序写。官网有数据表明,同样的磁盘,顺序写能到 600M/s,而随机写只有 100K/s。这
与磁盘的机械机构有关,顺序写之所以快,是因为其省去了大量磁头寻址的时间。
2)零复制技术
零拷贝即从page Cache 直接发送到NIC 省掉了机器底层的数据拷贝。
5. Zookeeper 在 Kafka 中的作用
Kafka 集群中有一个 broker 会被选举为 Controller,负责管理集群 broker 的上下线,所有 topic 的分区副本分配和 leader 选举等工作。
Controller 的管理工作都是依赖于 Zookeeper 的。 Controller是谁先和zookeeper建立连接,谁就是conrtoller
Leader选举
是很重要的一个知识点,这个视频只是大概说了一下,不是很深入,会另写一篇博客。
6. Kafka 事务
Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基
础上,生产和消费可以跨分区和会话,要么全部成功,要么全部失败。
- Producer 事务
为了实现跨分区跨会话的事务,需要引入一个全局唯一的 Transaction ID,并将 Producer
获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction
ID 获得原来的 PID。
为了管理 Transaction,Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就
是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction
Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic,这样即使整个服务重启,由于
事务状态得到保存,进行中的事务状态可以得到恢复,从而继续进行。 - Consumer 事务
上述事务机制主要是从 Producer 方面考虑,对于 Consumer 而言,事务的保证就会相对
较弱,尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访
问任意信息,而且不同的 Segment File 生命周期不同,同一事务的消息可能会出现重启后被
删除的情况。
生产者的事务和幂等性主要解决的是精准一致性的问题,加入了事务可以跨分区和跨会话。