让面试官直拍大腿的回答！谈谈你对Kafka数据存储原理的理解

一位5年工作经验的小伙伴面试的时候被问到这样一个问题，说”谈谈你对Kafka数据存储原理的理解“。

那么今天，我给大家来聊一聊我对这个问题的理解。

01

Topic主题

在Kafka中，这个用 来存储消息的队列叫做Topic，它是一个逻辑的概念，可以理解为一组消息的集合。

生产者和Topic以及Topic和消费者的关系都是多对多。一个生产者可以发送消息到多个Topic，一个消费者也可以从多个Topic获取消息（但是不建议这么做）。

生产者发送消息时，如果Topic不存在，Kafka默认会自动创建。

02

Partition分区

首先，Kafka为了实现横向扩展，它会把不同的数据存放在不同的Broker上，同时为了降低单台服务器的访问压力，把一个Topic中的数据分隔成多个Partition。在服务器上，每个Partition都有一个物理目录，Topic名字后面的数字标号即代表分区。比如创建一个名为mytopic的主题，数据目录被分布到了3台机器。

如图所示：

mytopic-0存在A节点，mytopic-1存在B节点，mytopic-2存在C节点。

03

Replica副本

另外，Kafka为了提高分区的可靠性，又设计了副本机制。我们创建Topic的时候，通过指定replication-factor副本因子，来确定Topic的副本数。当然，副本因子数必须小于等于节点数，否则会报错。这样就可以保证，绝对不会有一个分区的两个副本分布在同一个节点上，不然副本机制也失去了备份的意义了。

如图所示，创建了一个3个分区3个副本Topic a3part3rep，被均匀分布到了3个Broker节点上，每个Broker节点互为备份。

这些所有的副本分为两种角色，Leader对外提供读写服务。Follower唯一的任务就是从Leader异步拉取数据，图中红色的副本为Leade，也被均匀分布在各个节点上，可以保证读写均匀，这样的设计也称为单调读一致性。

04

Segment分段

Kakfa为了防止Log不断追加导致文件过大，导致检索消息效率变低，一个Partition超出一定大小的时候，就被切割为多个Segment来组织数据。在磁盘上，每个Segment由一个log文件和2个index文件组成。

如图所示，这三个文件是成套出现的。其中.index是用来存储Consumer的Offset偏移量的索引文件，.timeindex是用来存储消息时间戳的索引文件，log文件就是用来存储具体的数据文件。

以切割时记录的Offset值作为文件的名字。它的文件结构是这样的，如图所示：

05

Index索引

前面我们讲到Kafka设计了两种索引，一种是偏移量索引文件，记录的是Offset和消息在Log文件中的位置映射关系。一种是时间戳索引文件，记录的是时间戳和Offset的关系。为了提高检索效率Kafka并不会为每一条消息都会建立索引，而是采用稀疏索引。也就是说隔一批消息才产生一条索引记录。如图所示：

我们可以通过以参数来设置索引的稀疏程度。

相对来说，越稠密的索引检索数据更快，但是会消耗更多的存储空间；

越的稀疏索引占用存储空间小，但是插入和删除时所需的维护开销也小。

同样，时间戳索引也是采用稀疏索引设计。由于索引文件是以Offset命名的，所以Kafka在检索数据的时候，是采用二分法查找，效率就非常快。

06

结尾

以上就是我对Kafka数据存储原理的理解！