6.1.3 日志分段

╰+攻爆jí腚メ 2023-01-12 15:52 58阅读 0赞

#### 6.1.3 日志分段 ####

> 服务端处理每批追加到日志分段中的消息集，都是以nextOffsetMetadata作为起始的绝对偏移盘。因为这个起始偏移量总是递增的，所以每一批消息的偏移量也一直保持递增。我们可以得州的结论是：同一个分区的所有日志分段中，所有消息的偏移量都是递增的。如图6-11所示，上面的箭头从全局的日志分段角度看，下面每个日志分段中的箭头则只从当前的日志分段看，有下面的两个特点：

*  新创建日志分段的基准偏移盐，都比之前分段的基准偏移量要大；
 *  同一个日志分段中，新消息的偏移量也比之前消息的偏移盘要大。  
    ![在这里插入图片描述][20210414235303798.png]

如图6-12所示，客户端传递的每一批消息，它们的偏移量都是从0开始的相对偏移量。消息集追加到日志分段后，相对偏移量会被更新为绝对偏移量。每个日志分段都有一个基准偏移盘(segmentBaseOffset)，日志分段中每条消息的偏移量都是以这个基准偏移量为基础的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]

Kafka消息代理节点上的一个主题分区(TopicPartition)对应一个日志(Log)。每个日志有多个日志分段(LogSegment)，一个日志管理该分区的所有日志分段。下面列举了日志对象中与日志分段有关的代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]![在这里插入图片描述][20210414235339634.png]

这里最重要的是活动日志分段(activeSegment)，用到它的相关变量和方法有下面几个。

*  activeSegment被定义为一个方法，它会获取segments的最后一个元素，作为日志最新的活动分段。如果有新日志分段产生，就会被加入到segments的最后一个，这样再次调用activeSegment方法获取的就是新创建的日志分段。
 *  “下一个偏移盐元数据”(nextOffsetMetadata)被定义为一个变量，它的数据依赖于activeSegment，比如活动分段的下一个偏移量值(nextOffset)、活动分段的基准偏移量(baseOffset)、活动分段的大小(size)。
 *  日志的最新偏移盐(logEndOffset)表示下一条消息的偏移量，它取向nextOffsetMetadata的下一个偏移量，实际上是活动日志分段的下一个偏移量值。

“下一个偏移扯元数据”是一个LogOffsetMetadata对象。它的下一条消息偏移量(nextOffset),一般会随君’消息的追加z直发生变化。另外，因为消息追加到活动的日志分段，日志分段的大小(size)也会发生变化。“日志分段的大小”会用来判断当前日志分段是否达到阔值，如果达到阔值，日志就会创建一个新的日志分段，并把新创建的日志分段作为“当前活动的日志分段”。日志分段的“基准偏移盘”(baseOffset)一般不会变化，除非“当前日志分段”发生变化。“下一个偏移盘元数据”对象在追加消息过程中起到重要的作用，相关的步骤如下。

(1)追加消息前，使用nextOffsetMetadata的消息偏移量，作为这一批消息的起始偏移量。
    (2)如果滚动创建了日志分段，当前活动的日志分段会指向新创建的日志分段。
    (3)追加消息后，更新阳＜tOffsetMetadata的消息偏移量，作为下一批消息的起始偏移盘。

1.  日志的偏移量元数据  
    日志的偏移主元数据是日志的一个重要特征。客户端对消息的读写操作，都会用到日志的偏移量信息。如图6-13所示，写入消息集到日志，日志的“下一个偏移量”(nextOffset)会作为消息集的“起始偏移盘”。从日志读取消息时，不能超过日志的“结束偏移盘”(logEndOffset)或“最高水位”(high阳ter1’1ark)。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]

日志的偏移量结构包括3部分：消息的偏移量(messageOffset)、日志分段的基准偏移:Q:(segmentBaseOffset)、消息在日志分段中的物理位置(relatlvePosltionlnSegment)，且；中后两者不一定会有值。追加消息时使用的nextOffsetMetadata，这3个变i主都从当前活动的日志分段(actlveSegment)获取。相关代码如下：  
![在这里插入图片描述][202104142354268.png]

追加消息时，因为很明确地知道要写到日志的活动分段中，所以活动分段的基准偏移盐和！大小都是已知的，nextOffsetMetadata关于日志偏移量元数据的3个变量都有值。但读取时使用的日志偏移量元数据(比如结束偏移量、最高水位)只有消息的偏移盘(第一个变盘)，没有其他的两个变量信息。

如图6-14所示，读取和写入消息集时都会创建或更新LogOffsetMetadata。写入操作主要使用了Log的nextOffsetMetadata(图中虚线上半部分)。读取操作主要使用了Replica的logEndOffsetMetadata和highWatermarkMetadata(图中虚线下半部分)。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]

下面来看一个logEndOffsetMetadata和lnextOffsetMetadata关联的例子。日志的logEndOffsetMetadata方法获取的“结束偏移量元数据”，最终用到的是“下一个偏移量元数据”。调用这个方法的是副本的logEndOffset方法。相关代码如下：  
![在这里插入图片描述][20210414235450286.png]  
![在这里插入图片描述][20210414235459207.png]

为什么日志的“结束偏移盐”可以认为和“下一个偏移量”相等？如果相等的话，为什么不只用一个变量来统一表示？实际上，如图6-15所示，“下一个偏移盘”专门针对写人操作，“结束偏移量”则专门针对读取操作。这两个偏移量对应的元数据虽然相同，但是对应的客户端不同。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]

注意：Kafka的分区有主副本和各份副本，它们分布在不同的节，点上。不同节点上的副本都有一个日志文件。因为每个副本在对应的消息代理节点上都有日志文件，所以每个副本也都有日志的偏移量信息。日志(Log)和分区(Partition)之间并没有直接的关联，日志(Log)和副本(Replica)才有关联关系。分区通过管理主副本和备份副本，从而间接地管理所有副本中的日志。日志和副本是一一对应的，一个副本对应一个日志。但实际上在Kafka分布式存储系统中，因为存在主副本和各份副本，副本如果不是本地的，就没有日志。总结下：副本有主副本和备份副本之分，日志则有本地和远程之分。

2.滚动创建日志分段  
为消息集分配偏移盘后，日志会将消息追加到最新的日志分段。如果当前的日志分段放不下新追加的消息集，日志会采用“滚动”方式创建一个新的日志分段，并将消息集追加到新创建的日志分段中。如图6-16所示，滚动创建日志分段分为下面3个步骤。

(1)“当前活动的日志分段”指向旧的日志分段。
    (2)旧的日志分段空间不足，会创建新的日志分段。
    (3)“当前活动的日志分段”指向新的日志分段。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]

注意：采用滚动方式创建日志分段的好处是，要根据时间、大小或偏移量3种策略删除日志的部分数据，实现起来比较容易。每个日志分段不仅有对应的大小，也记录了基准偏移量。如果要删除指定偏移量之前的数据，只需要选择满足条件的部分日志分段，并不需妥获取分区的所有日志分段。  
判断是否需要创建新的日志分段，有下面3个条件。

*  当前日志分段的大小加上消息大小超过日志分段的｜调值(log.segment.bytes配置项)。
 *  离上次创建日志分段的时间到达一定需要滚动的时间(log.roll.hourS配置项)。
 *  索引文件满了。日志分段由数据文件和索引文件组成，第一个条件是数据文件满了，会创建新的日志分段；这里的第三个条件是索引文件满了，也会创建新的日志分段。

采用滚动方式创建日志分段的代码如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]![在这里插入图片描述][20210414235618970.png]

新创建日志分段的基准偏移量取自logEndOffset，实际上是nextOffsetMetadata的消息偏移量值(fTlessageOffset)，也是当前活动日志分段的下一个偏移量值(nextOffset)。如图6-17所示，假设已经有两个日志分段，第三个日志分段初始时nextOffsetMetadata的下一个偏移量等于10，基准偏移量等于10。客户端发送多批消息集，服务端的处理步骤如下。

(1)第一批消息有3条消息，追加到第三个日志分段，下一个偏移量改为13，基准偏移量仍是10。
    (2)第二批消息有5条消息，追加到第三个日志分段，下一个偏移量改为18，基准偏移盘仍是10。
    (3)第二批消息、有2条消息，追加到第三个日志分段，下一个偏移量改为20，基准偏移量仍是10。
    (4)第四批消息有10条消息，当前活动的日志分段即第三个日志分段放不下这10条消息。满足滚动条件，创建第四个日志分段。第四个日志分段的下一个偏移量初始时为20，基准偏移量也是20。当新创建的日志分段加入到segments后，当前活动的日志分段会指向新创建的日志分段。第四批的10条消息就会追加到第四个日志分段。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 7]

消息集追加到已有的日志分段或者新创建的日志分段，每个日志分段由数据文件和笨’引文件组成。数据文件的实现类是文件消息集(FileMessageSet)，它保存了消息集的具体内容。索引文件的实现类是偏移量索寻I(Offsetindex)，它保存了消息偏移量到物理位置的索引。

1.  数据文件  
    追加一批消息到日志分段，每次都会写到对应的数据文件中，同时间隔indexlntervalBytes大小才写入一条索引条目到索引文件中。假设一条消息占用IO字节，每隔100字节才会写入一个索引条目，即IO条消息才会写入一个索引条目。如果一批消息有500字节，因为只会调用一次日志分段的append()方法，所以最多也只会创建一个索引条目。相关代码如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 8]

消息集(ByteBufferMessageSet)写入到数据文件(FileMessageSet)，实际上是要将消息集中的字节缓冲区(ByteBuffer)写入到数据文件的文件通道中(FileChannel)。相关代码如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]

注意：日志分段的追加方法中，log.sizeinBytes()方法和messages.sizeinBytes方法的结果不一样。前者是数据文件的大小，后者是当前这才比消息的大小，数据文件包括了多批追加的消息集。

消息集存储到日志分段中只是简单的追加。但要查询指定偏移量的消息，如果一条条查询就太慢  
了，而建立索引文件的目的就是：快速定位指定偏移量消息在数据文件中的物理位置。

1.  索引文件  
    写人数据文件的每一个消息集，它的每条消息都带有消息的绝对偏移量、大小、内容。为数据文件建立索引文件的基本思路是：建立“消息绝对偏移量”到“消息在数据文件中的物理位置”的映射关系。索引文件的存储结构有下面3种形式。

*  为每条消息都存储这样的对应关系：“消息的绝对偏移量”到“消息在数据文件中的物理位置”。
 *  以稀疏的方式存储部分消息的绝对偏移2到物理位置的对应关系，减少内存占用。
 *  将绝对偏移盐改用相对偏移量，进一步减少内存的占用。

Kafka的索引文件采用第三种形式，具有以下特性。

*  索引文件映射偏移量到文件的物理位置，它不会对每条消息都建立索引，所以是稀疏的。
 *  索引条目的偏移ill存储的是相对于“基准偏移量”的“相对偏移量”，不是消息的“绝对偏移盘”。
 *  索引条目的“相对偏移量”和1物理位置各自占用4字节，即l个索引条目占用8字节。
 *  消息集的“消息绝对偏移量”占用8字节，索引文件的“相对偏移量”只占用4字节。
 *  消息集8字节的“消息绝对偏移量”减去8字节的“基准偏移量”，结果是4字节。
 *  偏移盘是有序的，查询指定的偏移量时，使用二分查找可以快速确定偏移量的位置。
 *  指定偏移主；如果在索引文件中不存在，可以找到小于等于指定偏移量的最大偏移量。
 *  稀疏索引可以通过内存映射方式，将整个索引文件都放入内存，加快偏移量的查询。

为了理解索引文件的几个特点，下面来看个例子。如图6-18所示，假设有1000条消息，每100条消息写满了一个日志分段，一共会有10个日志分段。客户端要查询偏移量为28的消息内容，如果没有索引文件，我们必须从第一个日志分段的数据文件中，从第一条消息一直往前读，直到找到偏移量为28的消息。有了索引文件后，我们可以在第一个日志分段的索引文件中，先找到偏移量等于20的物理位置39，然后再到数据文件中，从文件物理位置39开始往前读每一条消息，直到找到偏移量为28的消息。

索引文件通常比较小，可以直接放入内存。索引条目的键如果存储的是消息的绝对偏移量，那么每个索引条目占用12字节；如果存储的是消息的相对偏移量，每个索引条目只会占用8字节，可以减少三分之一的内存。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 10]

日志分段如果需要添加索引条目到索引文件，会先添加索引条目，然后才开始追加消息集到数据文件。索引文件的追加方法接收两个参数：第一个参数是追加消息集的起始绝对偏移fil(它表示消息集第一条消息的绝对偏移量，这个偏移量值是nextOffset，已经是上一个消息集的最后一条消息偏移量再加上一了)；第二个参数是消息集第一条消息在数据文件中的物理位骂A这两个参数都表示消息集第一条消息的信息，所以索引条目存储偏移量到物理位置的映射关系是准确的。相关代码如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 11]![在这里插入图片描述][20210414235749715.png]

这一节分析了消息集的追加流程，以及日志、日志分段、数据文件和索引文件这些概念。下面总结下这些概念之间的关联关系，以及在消息集追加过程中各自起到的作用。

*  一个日志由多个日志分段组成，日志管理了所有的日志分段。
 *  日志用segMents保存每个日志分段的基准偏移量到日志分段的映射关系。
 *  日志分段的基准偏移量是分区级别的绝对偏移量。
 *  日志分段中第一条消息的绝对偏移量也等于日志分段的基准偏移量。
 *  每个日志分段都由一个数据文件和一个索引文件组成。
 *  日志分段的数据文件和索引文件的文件名称以基准偏移量命名。
 *  数据文件保存每条消息的格式是：消息的绝对偏移量、消息的大小、消息的内容。
 *  索引文件保存消息偏移盐和消息在数据文件中的物理位置。
 *  索引文件中索引牵目的键存储值是：消息的绝对偏移量减去基准偏移量。
 *  索引文件可以通过内存映射的方式，将整个索引文件加载到内存中，加快文件的读取。

下一节我们分析消息的读取流程，和追加消息流程一样，也从日志开始，不会涉及上层的业务逻辑。

[20210414235303798.png]: /images/20221022/ddc3555f8c834fae86a9d4232ad60073.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]: /images/20221022/085b7abd141c4f26ba1149fab20b17af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210414235329430.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0,size_16,color_FFFFFF,t_70
[20210414235339634.png]: /images/20221022/258a7e0427164f26ae81c890c17fd0fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]: /images/20221022/8b6246734f2b4247bee8001f9a54a57c.png
[202104142354268.png]: /images/20221022/17ce2c3b4f144af19605839258fde3b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]: /images/20221022/62ea422628c5478d85d179fa8a8c01d1.png
[20210414235450286.png]: /images/20221022/015a1cf3c06b4d198875c338a25f98b9.png
[20210414235459207.png]: /images/20221022/15e6054d17a94a53a91e5111a5572772.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]: /images/20221022/8ac7ddc1cde04905bc0b4b1da546070e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]: /images/20221022/a5b9148d4b5149ea9518a56c3d8cdaf0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210414235608509.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0,size_16,color_FFFFFF,t_70
[20210414235618970.png]: /images/20221022/2f0860b73b244af683f4766a168a998d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 7]: /images/20221022/f62f3180839e47ec84be90ab7a1e111e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 8]: /images/20221022/e6bed20bc3d14f31a75ddc5dca29fde8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]: /images/20221022/795eb54f73b34c08a51fedd52e068bb7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 10]: /images/20221022/1567f2b7572c4a099f5afa090a9ff074.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20210414235739716.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0,size_16,color_FFFFFF,t_70
[20210414235749715.png]: /images/20221022/6c38cc8afde4420faf7a3472e1206e56.png