Hadoop3.2.1 【 HDFS 】源码分析 : Datanode 存储[一]

ゝ一纸荒年。 2022-11-22 00:07 253阅读 0赞

### List of articles ###

*  一. 前言
 *  二.Datanode磁盘存储结构
 *  三.DataStorage实现
 *   *  3.1. Storage类继承关系
     *  3.2. StorageInfo
     *  3.3. Storage.StorageState
     *  3.4. Storage.StorageDirector
     *   *  3.4.1. 文件夹操作
         *  3.4.2. 加锁／解锁操作
         *  3.4.3. 存储状态恢复操作

# 一. 前言 #

本文主要介绍Datanode的存储以及实现.

# 二.Datanode磁盘存储结构 #

尽管Datanode并不保存HDFS文件和目录的元数据， 但是Datanode还是需要保存一部分Datanode自身的元数据的， 这些元数据是通过Datanode磁盘存储上的一些文件和目录来保存的.

Datanode可以定义多个存储目录保存数据块， Datanode的多个存储目录存储的数据块并不相同， 并且不同的存储目录可以是异构的， 这样的设计可以提高数据块IO的吞吐率. \[比如多块磁盘.\]

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

■ **BP-451827885-192.168.8.156-1584099133244**： 这个目录是一个块池目录， 块池目录保存了一个块池在当前存储目录下存储的所有数据块， 在Federation部署方式中， Datanode的一个存储目录会包含多个以“BP”开头的块池目录。 BP后面会紧跟一个唯一的随机块池ID， 在这个示例中就是451827885。 接下来的IP地址192.168.8.156是当前块池对应的Namenode的IP地址。 最后一个部分是这个块池的  
创建时间。  
■ **VERSION文件**： 和Namenode以及JournalNode的VERSION文件类似， 块池目录的VERSION文件同样包含了文件系统布局版本（layoutVersion） 、 HDFS集群ID（clusterld） 以及创建时间（cTime） 等集群信息。 除此之外， 块池目录的VERSION文件还包含了以下信息。

*  storageType——存储类型， 在这个示例中， 存储类型被设置为Datanode。
 *  blockpoolID——块池ID， 这个字段的值与块池目录下保存的块池ID是一样的。

#Mon Nov 02 16:20:41 CST 2020
    storageID=DS-23b73402-fa18-451d-930f-831de2e8686e
    clusterID=CID-67c28180-c700-49d1-a3f4-07db5dc12a17
    cTime=0
    datanodeUuid=9efa402a-df6b-48cf-9273-5468f68cc42f
    storageType=DATA_NODE
    layoutVersion=-57

■ finalized/rbw： finalized和rbw目录都是用于存储数据块的， 包括数据块文件以及对应的校验和文件。 **rbw**（replica being written， 正在写入副本） 目录保存了正在由HDFS客户端写入当前Datanode的数据块。 **finalized目录包含了已经完成写入操作的数据块**， 由于这样的数据块可能非常多， 所以finalized目录会以特定的目录结构存储这些数据块。每个数据块对应 2 个文件，blk 文件存放数据，另外一个以 meta 结尾的存放校验和等元数据。

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

finalized目录下的subdir0保存真正要存储的数据, 以多个文件夹区分.比如 subdir0 , subdir1 , subdir2 …  
每个subdir\[xxx\]文件夹下默认有512个 , 两种类型的文件 blk\_xxxxxxx 和 blk\_xxxxxxx\_xxxxx.meta两种格式的文件.

■ lazyPersist: HDFS 2.X中引入了一个新的特性， 用于支持将临时数据写入内存， 然后通过懒持久化（lazyPersist） 方式写入磁盘。 如果用户开启了这个特性，lazyPersist目录就用于将内存中的临时数据懒持久化到磁盘。  
■ scanner.cursor ： DataNode 会定期的对每个 blk 文件做校验，这个文件是用来记录校验到哪个位置的。

{ 
      "lastSavedMs" : 1602641225594,
      "iterStartMs" : 1602641195229,
      "curFinalizedDir" : null,
      "curFinalizedSubDir" : null,
      "curEntry" : null,
      "atEnd" : true
    }

■ in\_use.lock:这是一个被Datanode线程持有的锁文件， 用于防止多个Datanode线程启动并且并发修改这个存储目录。

81891@MacBook-Pro-2.local

# 三.DataStorage实现 #

Datanode最重要的功能就是管理磁盘上存储的HDFS数据块。

Datanode将这个管理功能切分为两个部分：

*  ① 管理与组织磁盘存储目录（由dfs.data.dir指定） ， 如current、previous、 detach、 tmp等， 这个功能由DataStorage类实现；
 *  ②管理与组织数据块及其元数据文件， 这个功能主要由FsDatasetlmpl相关类实现。

## 3.1. Storage类继承关系 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70_pic_center 2]  
一个Storage可以定义多个存储目录， 存储目录由Storage的内部类StorageDirectory描述， StorageDirectory类定义了存储目录上的通用操作。 由于HDFS 2.X版本引入了Federation机制 ， Datanode会为多个块池保存数据块， HDFS定义了BlockPoolSliceStorage类来管理Datanode上的一个块池， 这个块池分布在Datanode配置的所有存储目录中。 DataStorage类会持有所有BlockPoolSliceStorage对象的引用， 并通过这些引用管理Datanode上的所有块池。

## 3.2. StorageInfo ##

StorageInfo用于描述存储的基本信息.

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

■ layoutVersion： 存储系统布局版本号， 当节点存储的目录结构发生改变或者fsimage和editlog的格式发生改变时， 存储系统布局版本号会更新。 这个版本号一般是负数。  
■ namespaceID： 存储系统命名空间标识。  
■ cTime： 存储系统创建时间。  
■ clusterID： 存储系统的集群ID。  
■ storageType： 节点类型， 有DATA\_NODE、 NAME\_NODE、 JOURNAL\_NODE等类型。

StorageInfo中定义的信息都存储在存储目录的VERSION文件中， 一个VERSION文件就是一个典型的Java Properties（属性） 文件，不同类型节点的VERSION文件还存储了其他特有的属性。

## 3.3. Storage.StorageState ##

StorageState定义了存储空间可能出现的所有状态。 在升级、 回滚、 升级提交、 检查点等操作中， 节点（Datanode或者Namenode） 的存储空间可能出现各种异常， 例如误操作、 断电、 宕机等情况， 这个时候存储空间就可能处于某种中间状态， 引入中间状态， 有利于HDFS从错误中恢复过来。 存储状态的确定， 是在StorageDirectory.analyzeStorage()方法中进行的.

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>状态</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>NON_EXISTENT</td> 
   <td>存储不存在</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>NOT_FORMATTED</td> 
   <td>未格式化</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>COMPLETE_UPGRADE</td> 
   <td>升级完成状态</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>RECOVER_UPGRADE</td> 
   <td>恢复升级状态</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>COMPLETE_FINALIZE</td> 
   <td>完成升级提交</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>COMPLETE_ROLLBACK</td> 
   <td>完成回滚操作</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>RECOVER_ROLLBACK</td> 
   <td>恢复回滚</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>COMPLETE_CHECKPOINT</td> 
   <td>完成检查点操作</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td>RECOVER_CHECKPOINT</td> 
   <td>恢复检查点操作</td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>NORMAL</td> 
   <td>正常状态</td> 
  </tr> 
 </tbody> 
</table>

Storage状态还与启动选项有关， 这些选项的存储在HdfsServerConstants类

/** Startup options */
      enum StartupOption{ 
        FORMAT  ("-format"),
        CLUSTERID ("-clusterid"),
        GENCLUSTERID ("-genclusterid"),
        REGULAR ("-regular"),
        BACKUP  ("-backup"),
        CHECKPOINT("-checkpoint"),
        UPGRADE ("-upgrade"),
        ROLLBACK("-rollback"),
        ROLLINGUPGRADE("-rollingUpgrade"),
        IMPORT  ("-importCheckpoint"),
        BOOTSTRAPSTANDBY("-bootstrapStandby"),
        INITIALIZESHAREDEDITS("-initializeSharedEdits"),
        RECOVER  ("-recover"),
        FORCE("-force"),
        NONINTERACTIVE("-nonInteractive"),
        SKIPSHAREDEDITSCHECK("-skipSharedEditsCheck"),
        RENAMERESERVED("-renameReserved"),
        METADATAVERSION("-metadataVersion"),
        UPGRADEONLY("-upgradeOnly"),
    	// 其他代码略....................
      }

在启动选项中， 与Storage状态相关的有以下几项。  
■ FORMAT： 格式化操作。  
■ REGULAR： 正常启动。  
■ UPGRADE： 升级操作。  
■ ROLLBACK： 回滚操作。  
■ FINALIZE： 提交升级操作。

## 3.4. Storage.StorageDirector ##

我们知道Datanode和Namenode都可以定义多个存储目录来存储数据，StorageDirectory是Storage的内部类， 定义了管理存储目录的通用方法。

StorageDirectory有5个字段:

// 存储目录的根， 就是java.io.File文件。
        final File root;              // root directory
    
        // 指示当前目录是否是共享的。
        // 例如在HA部署中， 不同的Namenode之间共享存储目录，
        // 或者在Federation部署中不同的块池之间共享存储目录。
        final boolean isShared;
    
        // 当前存储目录的类型。
        final StorageDirType dirType; // storage dir type
    
        // 独占锁， java.nio.FileLock类型，
        // 用来支持Datanode或者Namenode线程独占存储目录的锁操作。
        FileLock lock;                // storage lock
    
        // 权限信息
        private final FsPermission permission;
    
        // 存储目录的标识符。
        private String storageUuid = null;      // Storage directory identifier.
    
        // 位置信息
        private final StorageLocation location;

StorageDirectory的方法主要分为三类： 获取文件夹相关操作、 加锁／ 解锁操作、 存储状态恢复操作。

### 3.4.1. 文件夹操作 ###

获取当前存储目录结构中的各个文件／ 文件夹的方法，  
在HDFS升级过程中涉及的所有目录都可以通过StorageDirectory提供的方法获得：

■ getCurrentDir()——获取current目录。
    ■ getVersionFile()——获取current目录下的VERSION文件。
    ■ getPreviousDir()——获取previous目录。
    ■ getPreviousVersionFile()——获取previous目录下的VERSION文件。
    ■ getPreviousTmp()——获取previous.tmp目录。
    ■ getRemovedTmp()——获取removed.tmp目录。
    ■ getFinalizedTmp()——获取finalized.tmp文件。
    ■ getLastCheckpointTmp()——获取lastcheckpoint.tmp文件。
    ■ getPreviousCheckpoint()——获取previous.checkpoint文件。

### 3.4.2. 加锁／解锁操作 ###

Datanode磁盘存储结构中,存储目录下会有一个in\_use.lock文件，这个文件用于对当前存储目录加锁， 以保证Datanode进程对存储目录的独占使用。 当Datanode进程退出执行时， in\_use.lock文件会被删除。 StorageDirectory提供了tryLock()与unlock()两个锁方法， 分别实现了对存储目录加锁以及解锁的功能。

StorageDirectory中真正进行加锁操作的是tryLock()方法。 tryLock()方法会首先构造锁文件， 然后调用file.getChannel.lock()方法尝试获得存储目录的独占锁， 如果已经有进程占有锁文件， 那么file.getChannel.lock()就会返回一个null的引用， 表明有另一个节点运行在当前的存储目录上， tryLock()方法会抛出异常并退出执行。 如果加锁成功， tryLock()方法会在锁文件中写入虚拟机信息。  
加锁成功后， tryLock()方法会调用deleteOnExit()方法， 在Java虚拟机运行结束时删除in\_use.lock文件。

/**
         * Attempts to acquire an exclusive lock on the storage.
         * 
         * @return A lock object representing the newly-acquired lock or
         * <code>null</code> if storage is already locked.
         * @throws IOException if locking fails.
         */
        @SuppressWarnings("resource")
        FileLock tryLock() throws IOException { 
          boolean deletionHookAdded = false;
    
          //构造in_use.lock文件
          File lockF = new File(root, STORAGE_FILE_LOCK);
    
          //锁文件构造失败， 则退出执行
          if (!lockF.exists()) { 
            lockF.deleteOnExit();
            deletionHookAdded = true;
          }
          RandomAccessFile file = new RandomAccessFile(lockF, "rws");
          String jvmName = ManagementFactory.getRuntimeMXBean().getName();
          FileLock res = null;
          try { 
            //尝试在锁文件上加锁
            res = file.getChannel().tryLock();
    
            //已经有程序获得了锁， 那么直接抛出异常
            if (null == res) { 
              LOG.error("Unable to acquire file lock on path {}", lockF);
              throw new OverlappingFileLockException();
            }
            //加锁成功， 在锁文件中写入虚拟机信息
            file.write(jvmName.getBytes(Charsets.UTF_8));
            LOG.info("Lock on {} acquired by nodename {}", lockF, jvmName);
          } catch(OverlappingFileLockException oe) { 
            //已经有程序获得了锁， 则关闭锁文件， 返回null
            // Cannot read from the locked file on Windows.
            String lockingJvmName = Path.WINDOWS ? "" : (" " + file.readLine());
            LOG.error("It appears that another node {} has already locked the "
                + "storage directory: {}", lockingJvmName, root, oe);
            file.close();
            return null;
          } catch(IOException e) { 
            //读取锁文件失败， 则关闭锁文件， 抛出异常
            LOG.error("Failed to acquire lock on {}. If this storage directory is"
                + " mounted via NFS, ensure that the appropriate nfs lock services"
                + " are running.", lockF, e);
            file.close();
            throw e;
          }
          if (!deletionHookAdded) { 
            //加锁成功， 在虚拟机运行结束后， 删除锁文件
            // If the file existed prior to our startup, we didn't
            // call deleteOnExit above. But since we successfully locked
            // the dir, we can take care of cleaning it up.
            lockF.deleteOnExit();
          }
          return res;
        }
    
        /**
         * Unlock storage.
         * 
         * @throws IOException
         */
        public void unlock() throws IOException { 
          if (this.lock == null)
            return;
          this.lock.release();
          lock.channel().close();
          lock = null;
        }

### 3.4.3. 存储状态恢复操作 ###

Datanode在执行升级、 回滚、 提交操作的过程中会出现各种异常， 例如误操作、 断电、 宕机等情况。  
StorageDirectory提供了doRecover()和analyzeStorage()两个方法， Datanode会首先调用analyzeStorage()方法分析当前节点的存储状态， 然后根据分析所得的存储状态调用doRecover()方法执行恢复操作。

**analyzeStorage()**

analyzeStorage()方法用于在Datanode启动时分析当前Datanode存储目录的状态，Datanode存储目录的状态定义在Storage.StorageState类中， 对存储目录状态的分析还需要结合Datanode的升级机制以及Datanode的启动选项， 存储目录状态判断的逻辑如下。

■ NON_EXISTENT： 以非FORMAT选项启动时，目录不存在;或者目录不可写、路径为文件时， 存储目录状态都为NOT_EXISTENT状态。
    ■ NOT_FORMATTED： 以FORMAT选项启动时， 都为NOT_FORMATTED状态。
    ■ NORMAL： 没有tmp中间状态文件夹， 则存储目录为正常状态。
    ■ COMPLETE_UPGRADE： 存在current/VERSION文件， 存在previous.tmp文件夹，则存储目录为升级完成状态。
    ■ RECOVER_UPGRADE： 存在previous.tmp文件夹， 不存在current/VERSION文件， 存储目录应该从升级中恢复。
    ■ COMPLETE_ROLLBACK： 存在removed.tmp文件夹， 也存在current/VERSION文件， 则存储目录的回滚操作成功完成。
    ■ RECOVER_ROLLBACK： 存在removed.tmp文件夹， 不存在current/VERSION文件， 存储目录应该从回滚中恢复。
    ■ COMPLETE_FINALIZE： 存在finalized.tmp文件夹， 存储目录可以继续执行提交操作。

/**
         * 检查存储目录的一致性。
         * Check consistency of the storage directory.
         * 
         * @param startOpt a startup option.
         * @param storage The Storage object that manages this StorageDirectory.
         * @param checkCurrentIsEmpty if true, make sure current/ directory
         *                            is empty before determining to format it.
         *  
         * @return state { @link StorageState} of the storage directory 
         * @throws InconsistentFSStateException if directory state is not 
         * consistent and cannot be recovered.
         * @throws IOException
         */
        public StorageState analyzeStorage(StartupOption startOpt, Storage storage,
            boolean checkCurrentIsEmpty)
            throws IOException { 
    
          if (location != null && location.getStorageType() == StorageType.PROVIDED) { 
            // currently we assume that PROVIDED storages are always NORMAL
            // 如果是外部存储   目前，我们假设提供的存储始终为“正常”
            return StorageState.NORMAL;
          }
    
          assert root != null : "root is null";
          boolean hadMkdirs = false;
    
          String rootPath = root.getCanonicalPath();
    
    
          try { 
            // 检查存储是否存在
            // check that storage exists
            if (!root.exists()) { 
              //如果存储不存在或者
              // storage directory does not exist
              if (startOpt != StartupOption.FORMAT &&  startOpt != StartupOption.HOTSWAP) { 
                //如果不是格式化 或者 热切换 则状态为不存在
                LOG.warn("Storage directory {} does not exist", rootPath);
                return StorageState.NON_EXISTENT;
              }
              LOG.info("{} does not exist. Creating ...", rootPath);
              if (!root.mkdirs()) { 
                throw new IOException("Cannot create directory " + rootPath);
              }
              hadMkdirs = true;
            }
            // 不是目录
            if (!root.isDirectory()) { 
              LOG.warn("{} is not a directory", rootPath);
              // 提示不存在
              return StorageState.NON_EXISTENT;
            }
            // 是否可以写
            if (!FileUtil.canWrite(root)) { 
              // 提示不存在
              LOG.warn("Cannot access storage directory {}", rootPath);
              return StorageState.NON_EXISTENT;
            }
          } catch(SecurityException ex) { 
            // 权限异常 提示不存在
            LOG.warn("Cannot access storage directory {}", rootPath, ex);
            return StorageState.NON_EXISTENT;
          }
    
          //如果存储存在,则开始加锁
          this.lock(); // lock storage if it exists
    
          // 如果startOpt为HOTSWAP，则对于空目录返回NOT_FORMATTED，同时还会检查布局版本。
    
          // If startOpt is HOTSWAP, it returns NOT_FORMATTED for empty directory,
          // while it also checks the layout version.
          if (startOpt == HdfsServerConstants.StartupOption.FORMAT ||
              (startOpt == StartupOption.HOTSWAP && hadMkdirs)) { 
            if (checkCurrentIsEmpty) { 
              checkEmptyCurrent();
            }
            // 提示为格式化
            return StorageState.NOT_FORMATTED;
          }
    
          //是否 导入检查点
          if (startOpt != HdfsServerConstants.StartupOption.IMPORT) { 
            // 检测老的版本
            storage.checkOldLayoutStorage(this);
          }
    
          // check whether current directory is valid
          // 获取版本文件
          File versionFile = getVersionFile();
          // 版本文件是否存在
          boolean hasCurrent = versionFile.exists();
    
          // 检查文件是否存在
          // check which directories exist
          boolean hasPrevious = getPreviousDir().exists();
          boolean hasPreviousTmp = getPreviousTmp().exists();
          boolean hasRemovedTmp = getRemovedTmp().exists();
          // 检查是否有Finalized文件
          boolean hasFinalizedTmp = getFinalizedTmp().exists();
          boolean hasCheckpointTmp = getLastCheckpointTmp().exists();
    
          if (!(hasPreviousTmp || hasRemovedTmp
              || hasFinalizedTmp || hasCheckpointTmp)) { 
            // no temp dirs - no recovery
            if (hasCurrent)
              //版本文件存在 状态: 正常
              return StorageState.NORMAL;
            if (hasPrevious)
              // 存在previous 文件夹 , 报错, 版本文件丢失
              throw new InconsistentFSStateException(root,
                                  "version file in current directory is missing.");
            if (checkCurrentIsEmpty) { 
              //检查当前文件夹是否为空,如果为空则抛出异常.
              checkEmptyCurrent();
            }
            // 返回状态,未被格式化
            return StorageState.NOT_FORMATTED;
          }
    
          if ((hasPreviousTmp?1:0) + (hasRemovedTmp?1:0)
              + (hasFinalizedTmp?1:0) + (hasCheckpointTmp?1:0) > 1)
            // more than one temp dirs
            // 超过1个临时目录, 报错 : too many temporary directories
            throw new InconsistentFSStateException(root,
                                                   "too many temporary directories.");
    
          // # of temp dirs == 1 should either recover or complete a transition
          if (hasCheckpointTmp) { 
            // 是否有hasCurrent 文件 ? 是完成检查点操作 : 否  恢复检查点操作
            return hasCurrent ? StorageState.COMPLETE_CHECKPOINT
                              : StorageState.RECOVER_CHECKPOINT;
          }
    
          if (hasFinalizedTmp) { 
            if (hasPrevious)
              throw new InconsistentFSStateException(root,
                                                     STORAGE_DIR_PREVIOUS + " and " + STORAGE_TMP_FINALIZED
                                                     + "cannot exist together.");
            return StorageState.COMPLETE_FINALIZE;
          }
    
          if (hasPreviousTmp) { 
            if (hasPrevious)
              throw new InconsistentFSStateException(root,
                                                     STORAGE_DIR_PREVIOUS + " and " + STORAGE_TMP_PREVIOUS
                                                     + " cannot exist together.");
            if (hasCurrent)
              return StorageState.COMPLETE_UPGRADE;
            return StorageState.RECOVER_UPGRADE;
          }
          
          assert hasRemovedTmp : "hasRemovedTmp must be true";
          if (!(hasCurrent ^ hasPrevious))
            throw new InconsistentFSStateException(root,
                                                   "one and only one directory " + STORAGE_DIR_CURRENT 
                                                   + " or " + STORAGE_DIR_PREVIOUS 
                                                   + " must be present when " + STORAGE_TMP_REMOVED
                                                   + " exists.");
          if (hasCurrent)
            return StorageState.COMPLETE_ROLLBACK;
          return StorageState.RECOVER_ROLLBACK;
        }

**doRecover()**  
调用analyzeStorage()之后， Datanode就可以确定存储目录的状态了。 对于异常状态，可以通过调用doRecover()方法进行恢复， 使存储空间的状态恢复到NORMAL状态。

doRecover()的流程以COMPLETE\_ROLLBACK和RECOVER\_ROLLBACK为例。 如果当前状态是COMPLETE\_ROLLBACK， 只需将  
removed.tmp目录删除即可将存储目录状态恢复为NORMAL状态； 如果当前状态是RECOVER\_ROLLBACK， 只需将removed.tmp改名为current即可将存储目录状态恢复为NORMAL状态。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/647153f3786b4618972b074fa516de82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/a0aea178fee14929986d91dc4a8e20e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/92cfadafa4c44c7e9bf1ccf08502b5d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/8b61c5064fc6431c8629d88fb5e94fec.png