kafka⼯作流程及⽂件存储机制
1、Kafka⼯作流程
kafka中消息是以topic进⾏分类的，⽣产者⽣产消息，消费者消费消息，都是⾯向topic的
topic是逻辑上的概念，⽽partition是物理上的概念，每个partition对应⼀个log⽂件，该log⽂件中存储的就是producer⽣产的数据。producer ⽣产的数据会被不断追加到log⽂件的末端，且每条数据都有⾃⼰的offset
offset是⼀个long型的数字，通过这个offset可以确定⼀条在该partition下的唯⼀消息。在partition下是保证有序的，但是在topic下⾯没有保证有序性
消费者组中的每个消费者，都会实时记录⾃⼰消费到哪个offset以便出错恢复，从上次的位置继续消费
2、⽂件存储机制
2.1 存储机制
由于⽣产者⽣产的消息会不断追加到log⽂件末端，为防⽌log⽂件过⼤导致数据定位效率低，kafka采取了分⽚和索引机制，将每个partition 分为多个segment（逻辑上的概念，index+log⽂件）
每个partition（⽬录）相当于⼀个巨型⽂件被平均分配到多个⼤⼩相等的segment（⽚段）数据⽂件中（每个segment⽂件中消息数量不⼀定相等），这种特性也⽅便old segment的删除，即⽅便已被消费的消息的清理，提⾼磁盘的利⽤率。每个partition只需要⽀持顺序读写就
⾏，segment的⽂件⽣命周期由服务端配置参数（log.segment.bytes，ll.{ms,hours}等若⼲参数）决定
每个segment对应两个⽂件----“.index”和“.log”⽂件。分别表⽰为segment索引⽂件和数据⽂件（引⼊索引⽂件的⽬的就是便于利⽤⼆分查快速定位message位置）。这两个⽂件的命名规则为：
partition全局的第⼀个segment从0开始，后续每个segment⽂件名以当前segment的第⼀条消息的offset命名，数值⼤⼩为64位，20位数字字符长度，没有数字⽤0填充。
这些⽂件位于⼀个⽂件夹下（partition⽬录），改⽂件夹的命名规则：topic名+分区序号。例如，first这个topic有三个分区，则其对应的⽂件夹为first-0，first-1，first-2
[root@bigdata-02 kafka-logs]# tree
.
# partition⽬录(topic名称+分区序号)
├── analyze-0
│├── 00000000000000000000.index
│├── 00000000000000000000.log
# 0.8版本之前的kafka没有timeindex⽂件，这是kafka的具体时间⽇志
│├── 00000000000000000000.timeindex
│└── leader-epoch-checkpoint
├── analyze-1
│├── 00000000000000000000.index
│├── 00000000000000000000.log
│├── 00000000000000000000.timeindex
│└── leader-epoch-checkpoint
├── analyze-2
│├── 00000000000000000000.index
│├── 00000000000000000000.log
│├── 00000000000000000000.timeindex
│└── leader-epoch-checkpoint
├── cleaner-offset-checkpoint
├── __consumer_offsets-0
│├── 00000000000000000000.index
│├── 00000000000000000000.log
│├── 00000000000000000000.timeindex
│└── leader-epoch-checkpoint
├── __consumer_offsets-1
│├── 00000000000000000000.index
│├── 00000000000000000000.log
│├── 00000000000000000000.timeindex
│└── leader-epoch-checkpoint
。
。
。
├── log-start-offset-checkpoint
├── meta.properties
├── recovery-point-offset-checkpoint
└── replication-offset-checkpoint
index和log⽂件以当前segment的第⼀条消息的offset命名。
2.2 index和log⽂件
.index 索引⽂件存储⼤量的索引信息，.log数据⽂件存储⼤量消息数据（message），索引⽂件中的元数据指向对应数据⽂件中message的物理偏移地址。以index索引⽂件中的元数据3497为例，依次在数据⽂件中表⽰第三个message（在全局Partition中表⽰第368772个message），以及该消息的物理偏移地址为497
2.3 message的结构
kafka最新版本Segment的Log⽂件由多个Message组成，下⾯详细说明Message的物理结构，如图：
参数说明：
2.4 如何通过offset查message
先⼆分查获取对应index索引⽂件，获取到对应的物理offset，拿着物理offset去log数据⽂件顺序查对应消息，返回查到的消息。
例如：读取offset=368776的Message，需要通过如下两个步骤。
第⼀步：查segment File
00000000000000000000.index表⽰最开始的⽂件，起始偏移量（offset）为0；第⼆个⽂件00000000000000368770.index的起始偏移量为368770，依次类推。以起始偏移量命名并排序这些⽂件，只要根据offset⼆分查⽂件列表，就可以快速定位到具体⽂件。
当offset=368776时，定位到00000000000000368770.index|log。
第⼆步：通过segment File查Message
通过第⼀步定位到Segment File，当offset=368776时，依次定位到00000000000000368770.index的元数据物理位置和00000000000000368770.log的物理偏移地址，然后再通过00000000000000368770.log顺序查，直到offset=368776为⽌。
segment index file采取稀疏索引存储⽅式，可以减少索引⽂件⼤⼩，通过Linux mmap接⼝可以直接进⾏内存操作。稀疏索引为数据⽂件的每个对应message设置⼀个元数据指针，它⽐稠密索引节省了更多的存储空间，但查起来需要消耗更多的时间
3、数据⽬录结构
向主题topic-log中发送⼀定量的消息，某⼀时刻topic-log-0⽬录中的布局如下所⽰。
⽰例中第2个LogSegment对应的基准位移是133，也说明了该LogSegment中的第⼀条消息的偏移量为133，同时可以反映出第⼀个LogSegment中共有133条消息（偏移量从0⾄132的消息）。
注意每个LogSegment中不只包含“.log”“.index”“.timeindex”这3种⽂件，还可能包含 “.deleted”“.cleaned”“.swap”等临时⽂件，以及可能
的“.snapshot”“.txnindex”“leader-epoch-checkpoint”等⽂件。
Kafka 中的⽂件不只上⾯提及的这些⽂件，⽐如还有⼀些检查点⽂件，当⼀个Kafka服务第⼀次启动的时候，默认的根⽬录下就会创建以下5个⽂件：
├── cleaner-offset-checkpoint
├── meta.properties
├── recovery-point-offset-checkpoint
├── replication-offset-checkpoint
├── log-start-offset-checkpoint
kafka0.8之后消费者提交的位移是保存在 Kafka 内部的主题__consumer_offsets中的，初始情况下这个主题并不存在，当第⼀次有消费者消费消息时会⾃动创建这个主题。
在某⼀时刻，Kafka 中的⽂件⽬录布局如图所⽰。每⼀个根⽬录都会包含最基本的 4个检查点⽂件（xxx-checkpoint）和 meta.properties ⽂件。在创建主题的时候，如果当前 broker中不⽌配置了⼀个根⽬录，那么会挑选分区数最少的那个根⽬录来完成本次创建任务。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。