一个分区副本在节点上对应一个log文件夹，同时kafka为了防止文件过大引入了logSegment概念。将log切分成了多个logSegment，相当于将一个大文件切分成多个小文件。logSegment又对应磁盘上多个文件，一般有一个日志文件和两个索引文件，以及可能的其他文件。
向log中追加消息时是顺序写入，只有最后一个logSegment才能执行昔日如操作，此前的所有logSegment度不能写入数据。
为了便于消息的检索，每个logSegment中的日志文件(以.log结尾)对有对应的两个索引文件：偏移量索引文件(以.index结尾)和时间戳索引文件(以.timeindex结尾)。每个logSegment都有一个基准偏移量baseOffset，用来表示当前logSegment中第一条小消息的offset。偏移量是一个64位的长整型数，日志文件和两个索引文件都是根据基准偏移量命名的，名称固定为20位数字，没有达到的位数则用0填充。
除了以上文件外在一个kafka服务第一次启动的时候，默认的根目录下就会创建一下5个文件：
cleaner-offset-checkpoint，log-start-offset-checkpoint，meta-properties，recovery-point-offset-checkpoint，replication-offset-checkpoint
0.8-0.10版本之间为v0版本的日志文件格式
kafka-run-class.sh kafka.tool.DumpLogSegments --file $KAFKA_LOG/topic-create-0/000000000000000.log
0.10-0.11版本之间为v1版本的日志格式
这个版本比v0版本就多了一个timestamp字段，表示消息的时间戳
这个版本的attributes字段中的低3位和v0版本的一样，还是压缩类型，而第4个位也被利用起来了：1表示timestamp类型为createTime，而1表示timestamp类型为logAppendTime，其余保留。时间戳类型可由broker端参数log.message.timestamp.type来配置，默认为CreateTime，即采用生产者创建消息是的时间戳。
如果在创建ProducerRecord是没有显式指定消息的时间戳，那么KafakProducer也会在发送这条消息前自动添加上。下面是KafkaProducer中与此对应的一句关键代码
long timestamp = record.timestamp() == null ? time.milliseconds() : record.timestamp();
0.11版本后使用的是v2版本的日志
v2版本二中消息集称为Record Batch，而不是先前的Message Set。
v2版本的消息格式去掉了crc32，另外增加了legnth，timestamp delta，offset delta和headers，并且attributes字段被弃用了
Kafka日志中使用哪种压缩方式是通过参数compression.type来配置的，默认值为"producer"，表示保留生产者使用的压缩方式。这个参数还可以配置为gzip，snappy和lz4，如果参数compression.type为uncompressed则表示不压缩，这个是在broker端设置的，和生产者端的compression.type不一样。
当消息压缩是是将整个消息集进行压缩作为内层消息，内层消息整体作为外层的value
压缩的外层消息中的key为null，value字段中保存的是多条压缩消息，其中Record表示的是从crc32到value的消息格式。当生产者创建压缩消息的时候，对内层压缩消息设置的offset从0开始为每个内层消息分配offset，可以理解为是这个消息集中的相对offset。而外层offset的值为内层消息中最后一条消息的绝对offset。
计算公式
RO = IO_of_a_message - IO_of_the_last_message
AO = AO_of_last_inner_message + RO
kafka的索引文件以稀疏索引的方式构建消息的索引，每当写入一定量(有broker端参数log.index.interval.bytes指定，默认值为4096)时，偏移量索引文件和时间戳索引文件分别增加一个偏移量索引项和时间戳索引项。
稀疏索引通过MappedByteBuffer将索引文件映射到内存中，以加快索引的查询速度。查询指定偏移量时，使用二分查找法来快速定位偏移量的位置，如果指定的偏移量不在索引文件中，则会返回小于指定偏移量的最大偏移量。时间索引同理，当时间索引中记录的是时间和偏移量的对应值，而偏移量索引记录的是偏移量和磁盘物理值的对应关系。
日志分段文件切分包含以下几个条件，满足一个就可以了
消息的偏移量占用8个字节，由relativeOffset和position各4B来占用，除了文件名记录了该segment的第一条消息的偏移量后，索引文件中的都是相对偏移量。所以当相对偏移量超过了Integer.MAX_VALUE时将不再是4B了。
时间戳偏移量占用了12B，时间戳占8个字节，相对索引占4B。
查询流程
由broker端参数log.cleanup.policy确定，有两个值delete和compact，默认delete
主题级别的是cleanup.policy
在kafka日志管理中会有一个专门的日志删除任务来周期性地检查和删除不符合保留条件的日志分段文件，这个周期由broker端参数log.retention.check.interval.ms来配置，默认300000.
日志删除有3中保留策略：时间，日志大小和日志其实偏移量
该做法是把每个key里面的最新的value保留，而其余的删除的意思。
在cleaner-offset-checkpoint文件中将整个日志分为clean清理过的和dirty未清理过的。
firstDirtyOffset表示dirty部分的起始偏移量，而firstUncleanableOffset为dirty的截止偏移量，activeSegment不会参与日志压缩过程，broker端参数log.cleaner.min.compaction.lag.ms(默认为0)来配置消息在被清理前的最小保留时间，默认情况下firstUncleanableOffset等于activeSegment的baseOffset。
dirtyRatio = dirtyBytes / (cleanBytes + dirtyBytes) 这个是最小污浊率，为了防止日志补益药的频繁清理操作，kafka还是使用了参数log.cleaner.min.cleanable.ratio来限定可以进行清理操作的最小污浊率。kafka中的__consumer_offsets使用的就是日志压缩策略。
kafka中的每个日志清理线程会使用一个名为SkimpyOffsetMap的对象来构建key和offset的映射关系的哈希表。日志清理需要遍历两次日志文件，第一次遍历吧每个可以的哈细致和最后出现的offset都保留在SkimpyOffsetMap中。第二次遍历会检查每个消息是否符合保留条件。
默认情况下，SkimpyOffsetMap使用MD5来计算key的哈稀值，占用16B空间，为了防止哈希冲突国语频繁，也可以通过broker参数log.cleaner.io.buffer.load.factor(0.9)来调整负载因子。偏移量占用8B空间，股一个映射项占用大小24B。而SkimpyOffsetMap的大小是由log.cleaner.dedupe.buffer.size参数来确定(128M)，当然是所有删除线程的总和。SkimpyOffsetMap记录key的个数为128M * 0.9 / 24B = 5033164个key。
假设该日志没有进行过日志压缩，checkpoint中的记录为0，则将activeSegment前的日志分段经行一次压缩，这样每个非活跃的日志分段的大小都有所缩减，checkpoint的值也有所变化。执行第二次压缩是会合并一些较小的日志分段。压缩过程中将每一个需要保留的消息复制到一个以".clean"为后缀的临时文件中，此临时文件以当前日志分组中第一个日志分度的文件命名，压缩后将".clean"文件修改成".swap"文件，在删除了原来的日志文件后，在去掉后缀。