|
|
51CTO旗下网站
|
|
移动端

Kafka源码分析及图解原理之Broker端

一个topic可以有多个分区,每个分区的消息都是不同的。 虽然分区可以提供更高的吞吐量,但是分区不是越多越好。

作者:IT技术分享来源:今日头条|2019-09-20 08:54

 

首先从kafka如何创建一个topic来开始:

  1. kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test 

其中有这么几个参数:

  • --zookeeper:zookeeper的地址
  • --replication-factor:副本因子
  • --partitions:分区个数(默认是1)
  • --topic:topic名称

二.什么是分区

一个topic可以有多个分区,每个分区的消息都是不同的。 虽然分区可以提供更高的吞吐量,但是分区不是越多越好。一般分区数不要超过kafka集群的机器数量。分区越多占用的内存和文件句柄。 一般分区设置为3-10个。比如现在集群有3个机器,要创建一个名为test的topic,分区数为2,那么如图:

Kafka源码分析及图解原理之Broker端

partiton都是有序切顺序不可变的记录集,并且不断追加到log文件,partition中的每一个消息都回分配一个id,也就是offset(偏移量),offset用来标记分区的一条记录 ,这里就用官网的图了,我画的不好:

Kafka源码分析及图解原理之Broker端

2.1 producer端和分区关系

就图上的情况,producer端会把mq给哪个分区呢?这也是上一节我们提到的一个参数partitioner.class。 默认分区器的处理是:有key则用murmur2算法计算key的哈希值,对总分区取模算出分区号,无key则轮询。(org.apache.kafka.clients.producer.internals.DefaultPartitioner#partition)。当然了我们也可以自定义分区策略,只要实现org.apache.kafka.clients.producer.Partitioner接口即可:

  1. /** 
  2.  * Compute the partition for the given record. 
  3.  * 
  4.  * @param topic The topic name 
  5.  * @param key The key to partition on (or null if no key
  6.  * @param keyBytes serialized key to partition on (or null if no key
  7.  * @param value The value to partition on or null 
  8.  * @param valueBytes serialized value to partition on or null 
  9.  * @param cluster The current cluster metadata 
  10.  */ 
  11.  public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) { 
  12.  List<PartitionInfo> partitions = cluster.partitionsForTopic(topic); 
  13.  int numPartitions = partitions.size(); 
  14.  if (keyBytes == null) { 
  15.  int nextValue = nextValue(topic); 
  16.  List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic); 
  17.  if (availablePartitions.size() > 0) { 
  18.  int part = Utils.toPositive(nextValue) % availablePartitions.size(); 
  19.  return availablePartitions.get(part).partition(); 
  20.  } else { 
  21.  // no partitions are available, give a non-available partition 
  22.  return Utils.toPositive(nextValue) % numPartitions; 
  23.  } 
  24.  } else { 
  25.  // hash the keyBytes to choose a partition 
  26.  return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions; 
  27.  } 
  28.  } 

2.2 consumer端和分区关系

先来看下官网对于消费组的定义:Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group.

翻译:消费者使用一个消费者组名来标记自己,一个topic的消息会被发送到订阅它的消费者组的 一个 消费者实例上。

consumer group是用于实现高伸缩性,高容错性的consumer机制。如果有consumer挂了或者新增一个consumer,consumer group会进行重平衡(rebalance),重平衡机制会在consumer篇具体讲解,本节不讲。那么按照上面的图继续画消费者端:

Kafka源码分析及图解原理之Broker端

这里是最好的情况,2个partition对应1个group中的2个consumer。那么思考,如果一个消费组的消费者大于分区数呢?或者小于分区数呢?

如果一个消费组的消费者大于分区数,那么相当于多余的消费者是一种浪费,多余的消费者将无法消费消息。

如果一个消费组的消费者小于分区数,会有对应的消费者分区分配策略。一种是Range(默认),一种是RoundRobin(轮询),当然也可以自定义策略。 其实思想换汤不换药的啊,每个消费者能负载均衡的工作。 具体会在消费者篇讲解,这里不讲。

建议:配置分区数是消费者数的整数倍

三.副本与ISR设计

3.1 什么是副本

在创建topic的时候有个参数是--replication-factor来设定副本数。Kafka利用多份相同的备份保持系统的高可用性,这些备份在Kafka中被称为副本(replica)。副本分为3类:

  • leader副本:响应producer端的读写请求
  • follower副本:备份leader副本的数据, 不响应producer端的读写请求!
  • ISR副本集合:包含1个leader副本和所有follower副本(也可能没有follower副本)

Kafka会把所有的副本均匀分配到kafka-cluster中的所有broker上,并从这些副本中挑选一个作为leader副本,其他成为follow副本。如果leader副本所在的broker宕机了,那么其中的一个follow副本就会成为leader副本。leader副本接收producer端的读写请求,而follow副本只是向leader副本请求数据不会接收读写请求!

Kafka源码分析及图解原理之Broker端

3.2 副本同步机制

上面说了ISR就是动态维护一组同步副本集合,leader副本总是包含在ISR集合中。只有ISR中的副本才有资格被选举为leader副本。当producer端的ack参数配置为all(-1)时,producer写入的mq需要ISR所有副本都接收到,才被视为已提交。当然了,上一节就提到了,使用ack参数必须配合broker端的min.insync.replicas(默认是1)参数一起用才能达到效果,该参数控制写入isr中的多少副本才算成功。 如果ISR中的副本数少于min.insync.replicas时,客户端会返回异常org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。

要了解副本同步机制需要先学习几个术语:

  • High Watermark:副本高水位值,简称HW, 小于HW或者说在HW以下的消息都被认为是“已备份的”,HW指向的也是下一条消息! leader副本的HW值决定consumer能poll的消息数量!consumer只能消费小于HW值的消息!
  • LEO:log end offset,下一条消息的位移。 也就是说LEO指向的位置是没有消息的!
  • remote LEO:严格来说这是一个集合。leader副本所在broker的内存中维护了一个Partition对象来保存对应的分区信息,这个Partition中维护了一个Replica列表,保存了该分区所有的副本对象。除了leader Replica副本之外,该列表中其他Replica对象的LEO就被称为remote LEO。
Kafka源码分析及图解原理之Broker端

下面举个一个实际的例子(本例子参考胡夕博客),该例子中的topic是单分区,副本因子是2。也就是说一个leader副本,一个follower副本,ISR中包含这2个副本集合。我们首先看下当producer发送一条消息时,leader/follower端broker的副本对象到底会发生什么事情以及分区HW是如何被更新的。首先是初始状态:

Kafka源码分析及图解原理之Broker端

此时producer给该topic分区发送了一条消息。此时的状态如下图所示:

Kafka源码分析及图解原理之Broker端

如上图所见,producer发送消息成功后(假设acks=1, leader成功写入即返回),follower发来了新的FECTH请求,依然请求fetchOffset = 0的数据。和上次不同的是,这次是有数据可以读取的,因此整个处理流程如下图:

Kafka源码分析及图解原理之Broker端

显然,现在leader和follower都保存了位移是0的这条消息,但两边的HW值都没有被更新,它们需要在下一轮FETCH请求处理中被更新,如下图所示:

Kafka源码分析及图解原理之Broker端

简单解释一下, 第二轮FETCH请求中,follower发送fetchOffset = 1的FETCH请求——因为fetchOffset = 0的消息已经成功写入follower本地日志了,所以这次请求fetchOffset = 1的数据了。Leader端broker接收到FETCH请求后首先会更新other replicas中的LEO值,即将remote LEO更新成1,然后更新分区HW值为1——具体的更新规则参见上面的解释。做完这些之后将当前分区HW值(1)封装进FETCH response发送给follower。Follower端broker接收到FETCH response之后从中提取出当前分区HW值1,然后与自己的LEO值比较,从而将自己的HW值更新成1,至此完整的HW、LEO更新周期结束。

3.3 ISR维护

在0.9.0.0版本之后,只有一个参数:replica.lag.time.max.ms来判定该副本是否应该在ISR集合中,这个参数默认值为10s。意思是如果一个follower副本响应leader副本的时间超过10s,kafka会认为这个副本走远了从同步副本列表移除。

四.日志设计

Kafka的每个主题相互隔离,每个主题可以有一个或者多个分区,每个分区都有记录消息数据的日志文件:

Kafka源码分析及图解原理之Broker端

图中有个demo-topic的主题,这个topic有8个分区,每一个分区都存在[topic-partition]命名的消息日志文件 。在分区日志文件中,可以看到前缀一样,但是文件类型不一样的几个文件。比如图中的3个文件,(00000000000000000000.index、00000000000000000000.timestamp、00000000000000000000.log)。这称之为一个LogSegment(日志分段)。

4.1 LogSegment

以一个测试环境的具体例子来讲,一个名为ALC.ASSET.EQUITY.SUBJECT.CHANGE的topic,我们看partition0的日志文件:

Kafka源码分析及图解原理之Broker端

每一个LogSegment都包含一些文件名一致的文件集合。文件名的固定是20位数字,如果文件名是00000000000000000000代表当前LogSegment的第一条消息的offset(偏移量)为0,如果文件名是00000000000000000097代表当前LogSegment的第一条消息的offset(偏移量)为97。日志文件有多种后缀的文件,重点关注.index、.timestamp、.log三种类型文件即可。

  • .index:偏移量索引文件
  • .timeindex:时间索引文件
  • .log:日志文件
  • .snapshot:快照文件
  • .swap:Log Compaction之后的临时文件

4.2 索引与日志文件

kafka有2种索引文件,第一种是offset(偏移量)索引文件,也就是.index结尾的文件。第二种是时间戳索引文件,也就是.timeindex结尾的文件。

我们可以用kafka-run-class.sh来查看offset(偏移量)索引文件的内容:

Kafka源码分析及图解原理之Broker端

可以看到每一行都是offset:xxx position:xxxx。 这两者没有直接关系。

  • offset:相对偏移量
  • position:物理地址

那么第一行的offset:12 position:4423是什么意思呢?它代表偏移量从0-12的消息的物理地址在0-4423。

同理第二行的offset:24 position:8773的意思也能猜得出来:它代表偏移量从13-24的消息的物理地址在4424-8773。

我们可以再用kafka-run-class.sh来看下.log文件的文件内容,关注里面的baseOffset和postion的值。你看看和上面说的对应的上吗。

Kafka源码分析及图解原理之Broker端

4.3 如何用offset查找

按上面的例子,如何查询偏移量为60的消息

根据offset首先找到对应的LogSegment,这里找到00000000000000000000.index

通过二分法找到不大于offset的最大索引项,这里找到offset:24 position:8773

打开00000000000000000000.log文件,从position为8773的那个地方开始顺序扫描直到找到offset=60的消息

Kafka源码分析及图解原理之Broker端

【编辑推荐】

  1. Kafka设计原理看了又忘,忘了又看?
  2. Kafka为了追求极致的性能,有这11大优化之处
  3. Windows Core OS 最新消息:移植 Windows 10 操作中心
  4. 我以为我对Kafka很了解,直到我看了此文章
  5. 分布式消息系统的设计要点
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

用Python玩转excel

用Python玩转excel

让重复操作傻瓜化
共3章 | DE8UG

187人订阅学习

AI入门级算法

AI入门级算法

算法常识
共22章 | 周萝卜123

164人订阅学习

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

132人订阅学习

读 书 +更多

Eclipse插件开发方法与实战

本书分为4个部分共24章,以插件开发为中心,围绕插件开发主要介绍SWT/JFace的应用、插件扩展点的实现,以及GEF、EMF和RCP的相关知识。本书...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微