6.1.4 读取日志

女爷i 2023-01-15 04:55 128阅读 0赞

> Kafka中分区的主副本负责消息集的读写操作，消费者或者备份副本都会向主副本同步数据。客户端读取主副本的过程又叫作“拉取”，拉取主副本的消息集，一定会指定拉取偏移量。比如，前面章节中消费者会根据提交偏移盘，或者客户端设置的重置策略从指定的拉取位置(startOffset)开始拉取消息。服务端处理客户端的拉取请求，就会返回从这个位置开始读取的消息集。另外，客户端还会指定拉取的数据量(fetchSize)，这个值默认是Max.partition.fetch.bytes配置项，大小为lMB。

注意：客户均拉取消息时，还有一个fetch.Min.bytes配直项，大小为l字节。这个配直项表示服务端至少妥有l字节，才会返回响应结果给客户端；如果没有，就不需要返回结果。这个细节和本节的读取操作关系不是很大，所以会在后面分析“延迟的拉取请求”时再详细分析。

一个分区对应的日志管理了所有的日志分段，日志保存了基准偏移量和日志分段的映射关系。给定一个偏移盐，要读取从指定位置开始的消息集，最多i卖取fetchSize字节。因为fetchSize默认大小只有lMB，而日志分段对应的数据文件大小默认有lGB，所以通常来说服务端读取日志时，没有必要读取所有的日志分段，只需要选择其中的一个分段，就可以满足客户端的一次拉取请求。日志分段的选择要参考客户端设置的起始偏移量。如图6-19所示，假设日志管理的所有日志分段，它们的基准偏移盐’分别是［000,100,200,300,400,500)。客户端要读取起始偏移量等于350的消息，服端不需要从第一个日志分段开始读取，它可以直接跳到基准偏移岳为300的日志分段开始读取消息。这个操作叫作floor，即从所有基准偏移量中选择出小于等于350的最大值，最后的结果就是300。

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

日志的读取方法和调用日志分段的读取方法，有多个很容易泪洒的参数，下面是这些参数的说明。

*  startOffset。客户端拉取请求设置的起始偏移量，日志会根据这个起始偏移盘找：~，日志分段。
 *  maxlength。客户端拉取请求设置的拉取大小(fetchSize)，默认是lMB。
 *  maxOffset。最大的偏移量，备份副本的拉取，不会有这个值。如果是消费者的拉取，为了不让未提交的消息传给客户端，主副本会有一个“最高水位”标记，超过最高水位的消息不会被消费者拉取。
 *  maxPositiono日志分段读取方法的最后一个参数，即entry.getValue.size的值，entry表示通过startOffset选择的日志分段。获取臼志分段的大小，实际上是数据文件的大小。这个值是文件的物理位置，不是偏移量。它主要会在真正读取数据文件时使用，作为读取的氏度限制。比如，我们定位到了数据文件的起始读取位置后，这个数据文件有多大，最多只能读取到这个数据文件的末尾。

注意：要特别注意“偏移量”(offset)和“位直”(position)这两个名词的区别。“偏移量”针对消息而言，每条消息都有递增的偏移量。而“位置”主要针对数据文件，它表示的是消息在数据文件中的物理位直。后续的代码中有出现position的变量，一般都是针对数据文件的，而且lift文件的物理位直有关。

日志读取方法的相关代码如下：

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

上面的代码考虑了读取日志分段，但没有读取到消息的情况。代码会通过一个循环不断往后找下一个日志分段，直到读取到数据才会结束。我们只需要分析一个日志分段的读取过程，其他日志分段的读取过程都是类似的：每次循环都会更新日志分段(entry)，对应的最大物理位置(maxPosi.ti.on)也会更新。其他的变量，比如起始偏移岳、最大长度、最大偏移量，都不会变化(前两者是客户端设置的变量，最大偏移量则和具体的日志分段无关，它表示日志的最高水位)。如图6-20所示，因为日志分段是逻辑概念，它管理了物理概念的一个数据文件和索引文件。读取日志分段时，耍先读取索引文件再读取数据文件，不应该直接读取数据文件，具体步骤如下。

(1)根据起始偏移量(startOffset)读取索引文件中对应的物理位置。
    (2)查找索引文件最后返回：起始偏移盘对应的最近物理位置(startPosi.ti.on)。
    (3)根据起始位置直接定位到数据文件，然后开始读取数据文件的消息。
    (4)最多只能读取到数据文件的结束位置(r础Posi.ti.on)。

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

索引文件采用稀疏索引的方式，建立消息绝对偏移量到物理位置的映射关系。如果给定一个任意的目标偏移盐去查找索引文件，不一定能找到对应的索引条目。但索引文件中所有索引条目的偏移量都是递增的，我们可以找到离目标偏移量最近的索引条目偏移量(小于目标偏移量的最大值，和找日志分段的floor操作类似)。如图6-21所示，读取日志分段时，从索引文件到数据文件的步骤如下。

(2)根据物理位置328，直接定位到数据文件的328文件位置。
    (3)读取每条消息的偏移盘，但不读取消息内容。
    (4)步骤(3)最终会找到偏移盘为350的消息，得到物理位置448。
    (5)客户端定位到数据文件的448位置，开始真正读取起始偏移盏’为350的消息内容。

追加消息时，索引条目的偏移量是基于日志分段基准偏移量的相对偏移盘。由于客户端读取消息  
给的是绝对偏移量，因此在查询索引文件之前，要先将绝对偏移量减去日志分段的基准偏移盘，转换  
为相对偏移量。另外，数据文件每条消息的偏移量存储的是绝对偏移量，查找索引文件返回值也应该  
是绝对偏移量。但索引条目存储的是相对偏移量，最后返回的偏移量还要再加上基准偏移量。

如图6-22所示，客户端要查询起始偏移量为350的消息，首先会定位到文件名称为300的日志分段。查询索引文件时，将绝对偏移量350减去基准偏移量300得到50，再去查询索引文件。通过二分查找查到了相对偏移量为45的索引条目，返回结果要将相对偏移量的加上基准偏移量300得到绝对偏移量345。然后再定位到物理位置为328的数据文件并从绝对偏移量为345的消息开始读取，直到查询到绝对偏移量为350的消息。

注意：给定起始偏移量，查询索引文件，最后还要返回索引条目的偏移量(相对偏移量)，因为起始偏移量不一定存在于索引文件中。但索引条目的相对偏移量不能直接返回，要加上基准偏移量后才可以返回。对于客户端调用者来说，实际上它并不需妥知道索引文件底层存储相对偏移量还是绝对偏移量，而只需要知道给一个绝对偏移量，返回的也是绝对偏移量就行了。

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

读取日志会先选择一个日志分段，然后调用这个日志分段的read()方法读取数据。

1.  读取日志分段  
    下面的代码片段是针对“备份副本拉取请求”简化后的读取方法：

![在这里插入图片描述][20210421195307558.png]

其中translateOffset()方法将起始偏移量(startOffset)转换成它在数据文件中的起始物理位置(startPos".tion)。读取数据文件时，最大偏移量表示的数据文件大小(maxPosi.ti.on)和起始物理位置的差距，要和客户端设置的拉取大小(maxSi.ze)进行比较，取两者的最小值为读取长度(length)。

日志分段的log引用指的是文件消息集(Fi.leMessageSet)，而不是日志对象(Log)。文件消息集的读取方法会根据传人的开始位置和读取长度，构造一个新的文件消息集对象。读取文件的一般做法是：定位到指定的位置，读取出指定长度的数据，并且借助字节缓冲区来保存读取出来的数据。而这里读取出来后还要用对象来表示，所以直接创建新的文件消息集，类似于一个视图对象。相关代码如下：

![在这里插入图片描述][20210421195323956.png]

消费者和备份副本都会读取主副本的日志。如果日志分段的读取方法传入了最大偏移盘(maxOffset)，计算读取长度的逻辑会不同。下面的代码是读取日志分段的复杂版本，考虑了消费者和备份副本的区别，并且最后返回的是拉取数据信息对象(FetchDatainfo)，而不是读取数据文件返回的文件消息集(File问essageSet):

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

上面的代码有两处translateOffset()方法的调用：第一次是将起始偏移量(startOffset)转换为起始位置(startPosition)，第二次是将最大偏移量(maxOffset)转换为结束位置(endPosttion)。如图6-23(左)所示，“备份副本”拉取消息时没有使用最大偏移量。有图中消费者拉取消息时，最多只能读到最大偏移量对应的结束位置。

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

下面我们重点分析translateOffset()方法的实现。注意，将起始偏移量转换为文件的起始位置，需要分别查询索引文件和搜索数据文件。

1.  查找索引文件  
    每个日志分段都对应一个索引文件和数据文件。给定起始偏移量，先调用索引文件的lookup()查询方法，获得离起始偏移量最接近的物理位置。然后再调用数据文件的searchFor()方法，从指定的物理位置开始读取每条消息，直到找到起始偏移量对应的起始位置。相关代码如下：  
    ![在这里插入图片描述][20210421195511548.png]

注意：既然在搜索数搪丈件时，可以找到起始偏移量对应的起始位直，为什么不直接读取消息？这是因为转换方法只是负责找到起始位直，并不负责读取消息。具体的读取动作交给日志分段处理，而且日志分段的读取方法还会计算出要读取多少长度的消息。

下面我们先来分析查询索引文件的过程。索引文件用内存映射(mmap)的方式加载到内存中。由于在查询的过程中，可能会有新的索引条目添加到索引文件，导致内存映射发生变化，因此要先复制出一个字节缓冲区(i.dx)然后在这个字节缓冲区上查询，不需要和底层索引文件发生磁盘读取的操作。相关代码如下：

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

对索引文件进行二分查找返回的OffsetPosi.ti.on包含两个信息：偏移量和物理位置。偏移量不一定和起始偏移量对应，物理位置也不会和起始位置对应。查询返回的物理位置和返回的偏移量是对应的。相关代码如下：

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

索引文件中每个索引条目占用8字节，索引条目中偏移量和物理位置各向占用4字节。在查找过程中，需要读取出偏移量的值，然后和目标偏移量进行比较。如图6-24所示，relatlveOffset()方法会根据索引编号快速地定位到偏移量的位置，然后读取这个索引条目的偏移盘值。physical()方法会根据索引编号快速地定位到物理位置，然后读取出这个索引条目的物理位置值。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]

如图6-25所示，二分查找的low、m1.d、high表示索引编号，found值是索引条目：编号为mid的偏移量值。如果found值比目标偏移量(relOffset)小，在右边查找；如果found值比目标偏移盘大，在左边查找。如果最后还是没有查到，则返回low，因为要找的是小于或等于目标偏移量的值。

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

查询索引文件返回的偏移量和物理位置不一定表示起始偏移量和起始位置，还需要搜索数据文件才能确定起始偏移盘对应的起始位置。只有确定起始位置，日志分段才会调用数据文件的读取方法读取消息、。

1.  搜索数据文件  
    文件消息集的搜索方法中，第一个参数targetOffset表示要查询的目标偏移量，第二个参数startlngPositlon表示要从数据文件的哪个位置开始读取，它被用于最开始的文件定位。在读取数据文件的每条消息时，会判断消息的绝对偏移量是否等于起始偏移量，如果相等，表示找到这条消息；如果不相等，则继续读取下一条消息。相关代码如下：

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

注意：上面代码中的LogOverhead字节缓冲区(buffer变量)和字节缓冲区消息集的buffer虽然都是字节缓冲区，但表示的数据不一样。前者最多只会存放一条消息的绝对偏移量和消息大小，而后者存放了客户端发送一个消息集中的所有消息。另外，操作文件消息集的文件通道(channel)就意味着和底层的数据文件打交道了，文件通道的读取方法会读取出数据文件中的消息内容。

在6.1.2节“l消息集”中，消息集每条消息由3部分组成：消息的绝对偏移量、消息的大小、消息的内容。要查询数据文件中消息偏移量等于目标偏移量的消息，需要读取每条消息第一部分的值。如果不满足条件，就应该立即读取下一条消息的绝对偏移量。为了’快速读取每条消息的绝对偏移茧，我们只需要读取每条消息前两部分的数据，它们占用的字节缓冲区是固定的12字节(8字节的绝对偏移孟加上4字节的消息大小)。通过这种方式，我们不会读取消息内容，而是“跳跃式”在不同消息之间快速移动。

如图6-26所示，假设要查询目标偏移量为13的消息，数据文件的起始定位位置是0。查询第一条消息，它的偏移量为10，小于目标偏移量，于是读取第一条消息的大小，然后跳过这个大小定位到第二条消息的起始位置。查询第二条消息，它的偏移量为ll，也小于目标偏移盏，剩下的操作和第一条消息的处理方式类似。当查询到第四条消息时，消息的偏移量等于目标偏移盐，就可以结束并返回结果了。

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

现在已经分析完了日志的整个读取过程，在结束本节之前，再来看一个文件传输的优化方案。

1.  文件消息集视图  
    文件消息集是数据文件的实现类，这个类除了文件、文件通道外，还有两个代表文件位置的变量：开始位置(start)和结束位置(end)。文件消息集的读取方法根据a起始位置和读取大小，创建一个新的文件消息集视图。每次调用读取方法，都会生成一个新的文件消息集对象。我们仅在服务端处理客户端的拉取请求时才会调用消息集的读取方法。相关代码如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 13]  
    ![在这里插入图片描述][20210421195726296.png]

如果客户端的拉取请求读取的是同一个日志分段(一个日志分段够客户端的拉取请求读取很多次)，数据文件是同一个，说明同一个文件消息集会调用多次读取方法。虽然读取方法新创建的文件消息集视罔每次都不同，但所有的文件消息集都共用同一个文件和文件通道。为了区分不同的文件消息集，我们把和日志分段相关的文件消息集叫作“原始文件消息集”，调用“原始文件消息集”读取方法创建的新文件消息集叫作“文件消息集视图”。“原始文件消息集”的起始位置为0，结束位置为无限大，而且它们都不会变化。但读取方法创建的“文件消息集视图”，它们的起始和结束位置则是变化的。  
如图16-27所示，服务端读取日志分段创建了新消息集，并将消息集发送给客户端，具体步骤如下。

(1)日志分段新创建数据文件，文件和文件通道会用来创建一个文件消息集对象(原始文件消息
    (2)每次读取日志分段，都会调用原始消息集的读取方法。
    (3)原始消息集的每也读取方法，都会创建新的“文件消息集视图”。
    (4)文件消息集视图的WriteTo()方法，会将文件通道的字节直接传输到客户端网络通道。

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

读取方法创建的“文件消息集视图”，它的大小等于结束位置减去开始位置。因为是一个视图，所以一旦创建后，文件消息集就罔定下来。即使有新的消息集追加到日志分段，它们只会追加到“原始文件消息集”，不会改变已有的文件消息集视图。相关代码如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 15]

原始文件消息集和新创建的文件消息集视图使用场景不同。前者可以看作全局的文件消息集，后者是局部的文件消息集视图。如图6-28所示，这两种文件消息集互相关联，与之相关的操作如下。

(1)生产者产生的字节缓冲区消息集会追加到日志分段对应的文件消息集。
    (2)文件消息集会将字节缓冲区消息集写入到数据文件底层的文件通道中。
    (3)服务端处理客户端的拉取请求，读取日志分段，会读取文件消息集。
    (4)文件消息集的读取方法会生成一个局部的文件消息集视图，它和数据文件底层的文件通道相关。
    (5)局部文件消息集视图发送拉取响应结果给客户端，会将文件通道的字节直接传输给网络通道。

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

总结下来：全局的、可变的“原始文件消息集”除了接受消息集的追加，还会在每次处理客户端的拉取请求时，生成不百变的、局部的“文件消息集视图”。文件消息集视图的消息集表示一次拉取请求的分区数据，它最终会被封装到拉取响应中，通过服务端的网络通道发送给客户端。

1.  文件通道零拷贝传输  
    Java的文件ifili直(FileChannel)提供了两个和外部通道交互的传输方法。transferTo()方法会将当前文件通道的字节直接传输到可写通道中，transferFr0m()方法会将可读通道的字节直接传输到当前文件通道中。从方法名也可以看出，to是从本地传出到远程，fr0m是从远程传入到本地。相关代码如下：

![在这里插入图片描述][20210421195820355.png]

Kafka服务端处理客户端的拉取请求，在读取到文件消息集后，也会通过transferTo()方法将文件通道的字节传输到网络通道。如果从网络传输层来看，它的transferFr0m()方法接收文件通道参数，表示文件通道的字节会传入网络传输层的网络通道。相关代码如下：

![在这里插入图片描述][2021042119583039.png]

下面是文件消息集writeTo()方法的调用链，分区数据的发送对象会调用文件消息集的写入方法：

![在这里插入图片描述][20210421195842224.png]

如图6-29所示，发送对象中的数据是读取日志得到的文件消息集视图。发送对象和网络传输层的网络通道通过Kafka通道进行关联。调用Kafkaiil道的发送方法，将发送对象发送到网络通道中，这实际上是将文件消息集视图的文件通道传输给网络通道(图中右侧竖直的虚线)。

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

文件消息集视图中文件通道的字节传输给网络通道，并不一定会一次性全部发送完毕。如果分区数据要分成多次发送，会多次调用分区数据发送对象(PartitionDataSend)的writeTo()方法。注意：消息集之前的头部数据(即缓冲区的内容)只会写一次。相关代码如下：

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

客户端发送消息、集中每条消息的格式是：偏移量、消息大小、消息内容。服务端返回给客户端的分区数据格式为：分区编号、错误码、最高水位、消息集大小、消息集。如图6-30所示，分区数据的头部采用缓冲区方式，直接写到网络通道。缓冲区的内容必须全部写到网络通道，才可以接右写消息集的内容。消息集内容比较多，服务端发送数据时会采用transferTo()零拷贝的方式，将消息集中文件通道中的字节数据直接传输给网络通道。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 19]  
前面分析了一个分区对应的日志读写操作。总结下各种对象的关联关系：一个分区对应一个日志(Log)，一个日志下有多个日志分段(LogSegment )，每个日志分段都有一个数据文件(FileMessageSet)和索引文件(Offset!ndex )。下面分析日志的管理类(LogManager)。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]: /images/20221022/1dd5920cf37241daa403f2dc1be6faca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]: /images/20221022/980ec21f78c142649f084c64773a666e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]: /images/20221022/65ea304229604dddb51c1189b3c6d9f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]: /images/20221022/4a6cac398aba4d5489f490c8e03f3f49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]: /images/20221022/fb17afc1cf9c4c398906e7d041a98707.png
[20210421195307558.png]: /images/20221022/b1bf3d5067a04afeb3966b5f46f51c46.png
[20210421195323956.png]: /images/20221022/1d488e6223134ed78bcd2432c1e57a93.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]: /images/20221022/1780011cd3ef4568bed0e1d0d0909a9a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]: /images/20221022/5824fc0679c34fe69c0dc792c71e2366.png
[20210421195511548.png]: /images/20221022/c7b0f4f29a9a45acad4f31203cea6196.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 7]: /images/20221022/a3253a394ade4a149c545e10c248a8dd.png
[20210421195533500.png]: /images/20221022/d3e95c27cd174f1abffc02abc0388902.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 8]: /images/20221022/25d2102bda7144dc93e8c61eb467cd3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]: /images/20221022/c3b01070334841d2a5420d21cda15f04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 10]: /images/20221022/b0b0381dbc1f40359c6c98abbcc74f01.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 11]: /images/20221022/c5a2952960f444dcb118aef2882c6c41.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 12]: /images/20221022/0f31200f8ff749bc859be0fc8a12d549.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 13]: /images/20221022/6430cbde61a84785a0db3b78bf47b97b.png
[20210421195726296.png]: /images/20221022/e942485eb1c8406ba88ab9fdc5dbc9ef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 14]: /images/20221022/5eff1d03122b4e2b9d02bad71f7b5307.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 15]: /images/20221022/4f28555e673c481eb0b7bddb844c76a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 16]: /images/20221022/5290b52beb504ad2bbf481e4cbbcc160.png
[20210421195820355.png]: /images/20221022/9fe88a1bae78491f9e197b34f90b2a4c.png
[2021042119583039.png]: /images/20221022/5fe9e53957d24558aa869b217466bd4b.png
[20210421195842224.png]: /images/20221022/d81bbe9fe7414787b0bcf6f31a264dd2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 17]: /images/20221022/b00661a2254640c3b6b96dcba79000c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 18]: /images/20221022/aa90a7f267634355bc49f1821cd1bfe8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 19]: /images/20221022/595c308eceb14c17b2cd0cfd137f4e1b.png