您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
     
   
 订阅
  捐助
Kafka架构和原理
 
作者:青青子衿
236 次浏览     评价:  
 2020-1-20
 
编辑推荐:
本文讲述Kafka设计要点,Kafka消息存储方式,如何通过offset查找Message,希望对您有所帮助
本文来自于博客园,由火龙果软件Delores编辑、推荐。

Kafka架构如图:

整个架构中包括三个角色。

生产者(Producer):消息和数据生产者

代理(Broker):缓存代理,Kafka的核心功能

消费者(Consumer):消息和数据消费者

整体架构很简单,Kafka给Producer和Consumer提供注册的接口,数据从Producer发送到Broker,Broker承担一个中间缓存和分发的作用,负责分发注册到系统中的Consumer。

 

设计要点

 

 Kafka非常高效,下面介绍Kafka高效的原因,对理解Kafka非常用帮助。

直接使用Linux文件系统的Cache来高效缓存数据

采用Linux Zero-Copy提高发送性能。传统的数据发送需要发送4次上下切换,采用Sendfile系统调用之后,数据直接在内核态交换,系统上下文切换减少为2次。可以提高60%的数据发送性能。

Kafka以Topic来进行消费管理,每个Topic包含多个Part(ition),每个Part对应一个逻辑Log,由多个Segment组成。每个Segment中存储多条消息,消息ID由逻辑位置决定,即从消息ID可直接定位到消息的存储位置,避免ID到位置的额外映射。每个Part在内存中对应一个Index,记录每个Segment中的第一个消息偏移。

发布者发到某个Topic的消息会被均匀地分布到多个Part上(随机或根据用户指定的回调函数进行分布),Broker收到发布消息后往对应Part的最后一个Segment上添加该消息,当某个Segment上的消息条数到达配置值或消息发布时间超过阈值时,Segment上的消息便会被flush到磁盘上,只有flush到磁盘上的消息订阅者才能订阅到,Segment达到一定的大小后将不会再往该Segment写数据,Broker会创建新的Segment。

  

全系统分布式,即所有的Producer、Broker和Consumer都默认有多个,均为分布式的。Producer和Broker之间没有负载均衡机制。Broker和Consumer 之间利用ZooKeeper进行负载均衡。所有的Broker和Consumer都会在Zookeeper中进行注册,且Zookeeper会保存他们的一些元数据信息。如果某个Broker和Consumer发生了变化,那么所有其他的Broker和Consumer都会得到通知。

 

Kafka消息存储方式

Topic

 

 Topic是发布的消息的类别或者种子Feed名。对于每个Topic,Kafka集群都会维护这个分区的Log。如图

 

每个分区都是一个顺序的、不可变的消息队列,并且可以持续添加。分区中的消息都被分配了一个序列号,称之为偏移量(offset),在每个分区中此偏移量都是唯一的。

 

 Kafka集群保存所有的消息,直到他们过期,无论消息是否被消费。实际上,消费者所持有的仅有的元数据就是这个偏移量,也就是消费者在这个Log中的位置。在正常情况下,当消费者消费消息的时候偏移量也线性增加。但是实际偏移量由消费者控制,消费者可以重置偏移量,以重新读取消息。

 

 这种设计对消费者来说操作自如,一个消费者的操作不会影响其他消费者对此Log的处理。

分区

  

Kafka中采用分区的设计有两个目的:一是可以处理更多的消息,而不受单体服务器的限制,Topic拥有多个分区,意味着它可以不受限制地处理更多数据;二是分区可以作为并行处理的单元。

  

Kafka会为每个分区创建一个文件夹,文件夹的命名方式为topicName-分区序号,如图

 

而分区是由多个Segment组成的,是为了方便进行日志清理、恢复等工作。每个Segment以该Segment第一条消息的offset命名并以“.log”作为后缀。另外还有一个索引文件,他标明了每个Segment下包含的Log Entry的offset范围,文件命名方式也是如此,以“.index”作为后缀,如下:

索引和日志文件内部的关系,如图:

索引文件存储大量元数据,数据文件存储大量消息(Message),索引文件中的元数据指向对应数据文件中Message的物理偏移地址。以索引文件中的元数据3,497为例,依次在数据文件中表示第三个Message(在全局Partition中表示第368772个message),以及该消息的物理偏移地址为497.

 

 Segment的Log文件由多个Message组成,下面详细说明Message的物理结构,如图:

参数说明

如何通过offset查找Message

例如,读取offset=368776的Message,需要通过如下两个步骤。

第一步:查找Segment File.

00000000000000000000.index表示最开始的文件,其实偏移量(offset)为0;第二个文件00000000000000368769.index的其实偏移量为368770(368769+1),依次类推。以其实偏移量命名并排序这些文件,只要根据offset**二分查找**文件列表,就可以快速定位到具体文件。

 

 当offset=368776时,定位到00000000000000368769.index|log。

第二步:通过Segment File 查找Message。

  

通过第一步定位到Segment File,当offset=368776时,依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址,然后再通过00000000000000368769.log顺序查找,知道offset=368776为止。

 

 Segment Index File采取稀疏索引存储方式,可以减少索引文件大小,通过Linux mmap接口可以直接进行内存操作。稀疏索引为数据文件的每个对应Message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来需要消耗更多的时间。

 
   
236 次浏览  评价: 差  订阅 捐助
相关文章

我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
 
相关文档

数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
相关课程

高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优