深入理解kafka核心设计与实践原理_读书笔记 第5章 日志存储(上)

5.1文件目录

    Kafka引入了日志分段LogSegment 的概念，将Log切分为多个LogSegment。
    
    Log中追加消息时是顺序写入的，且只能写入最后一个LogSegment，此前的都不能写入。

    每个LogSegment 对应于磁盘上的一个日志文件和两个索引文件 和 其他文件。

    偏移量索引文件(.index)和时间戳索引文件(.timeindex)。

    每个LogSegment有基准偏移 baseOffset,表示当前LogSegment中第一条消息的offset。

    每个LogSegment还可能会包含".delete",".clean"等临时文件

5.2 日志格式的演变

5.2.1 v0版本

	Kafka消息格式的第一个版本通常称为v0版本，在 Kafka 0.10.0之前都采用的这个消息格式

5.2.2 v1版本

    Kafka从 0.10.0 版本开始到 0.11.0 版本之前所使用的消息格式版本为v1  

    v1 比 v0 版本就多了一个 timestamp 字段，表示消息的时间戳。 

5.2.3 消息压缩

    kafka将多条消息一起压缩。通过参数 compression.type配置。

    默认值为producer，表示保留生产者使用的压缩方式。

    参数还可以配置为gzip、snapp、lz4

5.2.4 变长字段

    Kafka 0.11.0 版本开始所使用的消息格式版本为v2，这个版本的消息相 vO v1版本而言改动很大，
   
    同时还参考了Protocol Buffer 引入了变长整型（ Varints ）和ZigZag编码。

    Varints 是使用一个或多个字节来序列化整数的一种方法。

5.2.5 v2版本

    v2版本中消息集称为 Record Batch,而不是先前的 MessageSet,其内部也包含了一条或多条消息

    Record内部字段大量采用了 Varints

5.3 日志索引

    本章开头就提及了每个日志分段文件对应了两个索引文件，主要用来提高查找消息的效率。
    
    偏移量索引文件用来建立消息偏移量（ offset ）到物理地址之间的映射关系，快速定位消息物理文件；

    时间戳索引文件则根据指定的时间戳（ timestamp ）来查找对应的偏移量信息。

5.3.1 偏移量索引

    偏移量索引文件的格式如下

        relativeOffset      position
            4B(大小)            4B 

    使用kafka-dump-log.sh解析.index 文件，示例如下：

        bin/kafka-dump-log.sh -- les /tmp/kafka-logs/topic-log-0/00000000000000000000.index
       
        Dumping /tmp /kafka logs/topic-log- 0/00000000000000000000 .index
        offset : 6  position: 156
        offset : 14 position: 459
        offset : 22 posit on: 656
        offset : 26 position: 838
        offset : 31 position: 1050

        (这里的offset 指的是 relativeOffset)

(1) relativeOffset

    相对偏移量，表示相对于 baseOffset 的偏移量，占用4字节。索引文件名为baseOffset的值


    消息的偏移量offset占用8个字节，也可以称为绝对偏移量。

    索引项中没有直接使用绝对偏移量，而改为只占用4个字节的相对偏移量，可以减小索引文件占用的空间。

    relativeOffset = offset - baseOffset。

(2) position

    物理地址，也就是消息在日志分段文件中对应的物理位置，占用4个字节。

(3) 查找过程

     参考图5-10，如何查找偏移量为268的消息

     ①首先定位baseOffset 小于且最接近 268 的日志分段文件logsegment。此处为xxx251.log

         定位xxx251.log，是不是顺序查找，而是用了跳跃表的结构。

         每个日志对象中使用了ConcurrentSkipListMap 来保存各个日志分段，

         每个日志分段的 baseOffset 作为 key，这样可以偏移量来快速定位到消息所在的日志分段

     ②计算relativeOffset：offset - baseOffset 即 268 - 251 = 17

     ③在xxx251.index文件中 找到relativeOffset<=17 的 position

             通过二分法在xxx251.index文件中找到不大于17的最大索引项，

     ④在 xxx251.log中定位 position对应的消息

5.3.2 时间戳索引

    时间戳索引的格式如下：

        timestamp   relativeOffset
         8B           4B

(1) timestamp

	当前日志分段最大的时间戳。

    时间戳索引文件中包含若干时间戳索引项 每个追加timestamp 必须大于之前 timestamp,否则不予追加

(2) relativeOffset

	时间戳所对应的消息的相对偏移量。

(3) 查找过程

    如果要查找指定时间戳 targetTimeStamp = 1526384718288 开始的消息，

    首先是找到不小于指定时间戳的日志分段。这里无法使用跳跃表来快速定位到相应的日志分段， 

    需要一下四个步骤：

        ①:将targetTimeStamp 和每个日志分段中的最大时间戳 largestTimeStamp 对比，

          直到找到不小于 targetTimeStam largestTimeStamp 所对应的日志分段。


        ②:在时间戳索引文件中使用二分法查找不大于targetTimeStamp 最大索引项，
            
           即[152638471 8283, 28 ］，如此便找到了相对偏移28
        
        ③:在偏移量索引文件中使用二分算法查找到不大于 28 的最大索引项，即［26, 838
        
        ④:从①中找到日志分段文件中的 838 的物理位置开始查找不小于 targetTimeStamp的消息

5.4 日志清理

    Kafka 提供了两种日志清理策略

    (1)日志删除(Log Retention): 按照一定的保留策略直接删除不符合条件的日志分段。
    (2)日志压缩(Log Compaction):针对每个消息的key进行整合,对于有相同key的不value值,只保留最后一个版本。


    参数 log.cleanup.policy 来设置日志清理策略。默认"delete",即日志删除。
    设置成"compact" 即是日志压缩

5.4.1 日志删除

    当前日志分段的保留策略有3种: 基于时间的保留策略、基于日志大小的保留策略和基于日志起始偏移量的保留策略。

1.基于时间

    日志删除任务会检查当前日志文件中是否有保留时间超过设定的阈值，寻找可删除日志分段集合。

    默认情况配置log.retention.hours参数 其值为168,即保留时间为7天。

2.基于日志大小

    日志删除任务会检查当前日志的大小是否超过设定的阈值，寻找可删除的日志分段的文件集合。

    单个日志分段的大小由broker 参数log.segment.bytes配置，默认1073741824, 即1GB。

3.基于日志起始偏移量

    基于日志起始偏移量的保留策略的判断依据是，某日志分段的下一个日志分段的起始偏移量baseOffset 
    
    是否小于等于 logStartOffset ，若是，则可以删除此日志分段。

5.4.2 日志压缩

    Log Compaction 对于有相同 key 的不同 value 值，只保留最后一个版本。