底层中间件-redis介绍

傷城~ 2022-11-03 00:45 157阅读 0赞

## 一、redis简介 ##

## 二、Redis基本数据类型（五种） ##

redis 自身是一个map，其中所有的数据都是采用`key:value` 的形式进行存储；数据类型指的是存储的数据的类型，也就是Value部分的类型，key部分永远都是字符串类型

> 高级数据类型有三种：Bitmaps，HyperLogLog， GEO

#### 1. String字符串（对应Java-String） ####

*  存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
 *  存储数据格式：一个存储空间保存一个数据
 *  存储内容：通常使用字符串，如果字符串以整数的形式展示可以作为数字操作使用
 *  使用场景：大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应的主键 id 必须保证统一性 ，不能重复；使用这个作为主键自增可以确保唯一性
    
    **redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70]

#### 2. Hash哈希散列列表（对应Java-HashMap） ####

*  存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
 *  需要的存储结构：一个存储空间保存多个键值对数据
 *  hash类型：底层使用哈希表结构实现数据存储
 *  使用场景： 电商网站购物车设计与实现；应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计

> 1.  hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应值为null
> 2.  每个hash可以存储2的32次方减1个键值对

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

#### 3. List列表（对应Java-LinkedList） ####

*  数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
 *  需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
 *  list类型：保存多个数据，底层使用双向链表存储结构实现
 *  业务场景：朋友圈点赞，按照点赞顺序显示点赞好友信息；应用于具有操作先后顺序的数据控制

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

#### 4. Set集合（对应Java-HashSet） ####

*  新的存储需求：存储大量的数据，在查询方面提供更高的效率
 *  需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
 *  set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的
 *  应用场景：应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐， 大V推荐等；应用于同类型数据的快速去重

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

#### 5. SortedSet（对应Java-TreeSet） ####

*  新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式
 *  需要的存储结构：新的存储模型，可以保存可排序的数据
 *  sorted\_set类型：在set的存储结构基础上添加可排序字段
 *  应用场景：票选广东十大杰出青年，各类综艺选秀海选投票 各类资源网站TOP10（电影，歌曲，文档，电商，游戏等） 聊天室活跃度统计；为所有参与排名的资源建立排序依据

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

## 三、Redis持久化 ##

**什么是持久化**：利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化

**为什么要持久化**：防止数据的意外丢失，确保数据安全性

### 1. 持久化方式 ###

RDB: 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

AOF: 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

### 2. RDB ###

#### 2.1 save指令工作原理-手动执行一次保存操作 ####

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

#### 2.2 bgsave指令工作原理-手动启动后台保存操作-但不是立即执行 ####

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

#### 2.3 save操作配置自动执行-原理 ####

满足限定时间范围内key的变化数量达到指定数量即进行持久化

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

#### 2.4 RDB的优点 ####

RDB是一个紧凑压缩的二进制文件，存储效率较高

RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景

RDB恢复数据的速度要比AOF快很多

应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

#### 2.5 RDB的缺点 ####

RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据

bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

### 3. AOF ###

#### 3.1 AOF的产生 ####

RDB的弊端：

*  存储数据量较大，效率较低 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低 ；
 *  大数据量下的IO性能较低
 *  基于fork创建子进程，内存产生额外消耗
 *  宕机带来的数据丢失风险

解决思路：

*  不写全数据，仅记录部分数据
 *  降低区分数据是否改变的难度，改记录数据为记录操作过程
 *  对所有操作均进行记录，排除丢失数据的风险

#### 3.2 概念 ####

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

#### 3.2 AOF写数据原理 ####

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

**AOF写数据的三种策略：**

*  always(每次） 每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
 *  everysec（每秒） 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置 在系统突然宕机的情况下丢失1秒内的数据
 *  no（系统控制） 由操作系统控制每次同步到AOF文件的周期，整体过程不可控

#### 3.2 AOF重写 ####

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。

*  **AOF重写的作用：**

降低磁盘占用量，提高磁盘利用率

提高持久化效率，降低持久化写时间，提高IO性能

降低数据恢复用时，提高数据恢复效率

*  **AOF重写规则：**

进程内已超时的数据不再写入文件

忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

对同一数据的多条写命令合并为一条命令

如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

*  **AOF重写方式：** \-手动重写/自动重写

#### 3.3 AOF手动重写 --bgRewriteAof指令工作原理 ####

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

#### 3.4 AOF重写流程 ####

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

### 4. RDB VS AOF ###

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

*  对数据非常敏感，建议使用默认的AOF持久化方案
    
     *  AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。
     *  注意：由于AOF文件存储体积较大，且恢复速度较慢
 *  数据呈现阶段有效性，建议使用RDB持久化方案
    
     *  数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
     *  注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
 *  综合对比
    
     *  RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
     *  如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
     *  如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
     *  灾难恢复选用RDB
     *  双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

## 四、Redis过期策略和内存淘汰机制 ##

### 1. 数据删除策略 ###

在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或 内存泄露

#### 1.1 定时删除 ####

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作

*  优点：节约内存，到时就删除，快速释放掉不必要的内存占用
 *  缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
 *  总结：用处理器性能换取存储空间（拿时间换空间）

#### 1.2 惰性删除 ####

数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据 ，发现已过期，删除，返回不存在

*  优点：节约CPU性能，发现必须删除的时候才删除
 *  缺点：内存压力很大，出现长期占用内存的数据
 *  总结：用存储空间换取处理器性能 expireIfNeeded() （拿时间换空间）

#### 1.3 定期删除 ####

周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

*  特点1：CPU性能占用设置有峰值，检测频度可自定义设置
 *  特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
 *  总结：周期性抽查存储空间 expireIfNeeded() （随机抽查，重点抽查）

#### 1.4 对比 ####

定时删除 节约内存，无占用 不分时段占用CPU资源，频度高 拿时间换空间

惰性删除 内存占用严重 延时执行，CPU利用率高 拿空间换时间

定期删除 内存定期随机清理 每秒花费固定的CPU资源维护内存 随机抽查，重点抽查

### 内存淘汰机制 ###

…

## 五、主从复制 ##

### 1. 主从复制由来 ###

**单机redis的风险与问题**

问题一：机器故障

由于硬盘故障系统崩溃导致的数据丢失，很有可能对业务造成灾难性打击

问题二：容量瓶颈

由于内存不足，硬件条件跟不上很容易达到容量瓶颈

解决： 为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服 务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续 提供服务，实现Redis的高可用，同时实现数据冗余备份。

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

### 2. 主从复制简介 ###

主从复制即将master中的数据即时、有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责： master：写数据，执行写操作时，将出现变化的数据自动同步到

slave：读数据

### 3. 主从复制的作用 ###

*  读写分离：master写、slave读，提高服务器的读写负载能力
 *  负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数 量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
 *  故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
 *  数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
 *  高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

### 4. 主从复制工作流程 ###

建立连接阶段（即准备阶段）

数据同步阶段

命令传播阶段

#### 4.1 阶段一、建立链接阶段 ####

建立slave到master的连接，使master能够识别slave，并保存slave端口号  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 13]

> slave断开连接后，不会删除已有数据，只是不再接受master发送的数据

#### 4.2 阶段二、数据同步阶段 ####

在slave初次连接master后，复制master中的所有数据到slave

将slave的数据库状态更新成master当前的数据库状态

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

##### 数据同步阶段Master说明 #####

*  如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
 *  制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已 经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态
 *  master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执 行bgsave命令和创建复制缓冲区

##### 数据同步阶段Slave说明 #####

*  为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
 *  数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送 命令
 *  多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果 master带宽不足，因此数据同步需要根据业务需求，适量错峰
 *  slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟 较大，数据一致性变差，应谨慎选择

#### 4. 阶段三、命令传播阶段 ####

当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的 状态，同步的动作称为命令传播

master将接收到的数据变更命令发送给slave，slave接收命令后执行命令

##### 4.1 命令传播阶段的部分复制 #####

*  播阶段出现了断网现象 ：

网络闪断闪连时忽略；短时间网络中断进行部分复制； 长时间网络中断时进行全量复制

*  部分复制的三个核心要素：

**服务器的运行 id（run id） ；主服务器的复制积压缓冲区 ；主从服务器的复制偏移量**

##### 4.2 服务器运行ID #####

概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id

作用：运行id被用于在服务器间进行传输，识别身份 如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别

实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发 送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid

##### 4.3 复制缓冲区 #####

概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命 令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区

由来：每台服务器启动时，如果开启有AOF或被连接成为master节点，即创建复制缓冲区

作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）

数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 15]

##### 4.4 复制缓冲区工作原理 #####

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

##### 4.5 主从复制偏移量 #####

概念：一个数字，描述复制缓冲区中的指令字节位置

分类：

master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个）

slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个）

数据来源： master端：发送一次记录一次 slave端：接收一次记录一次

作用：同步信息

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70]: /images/20221024/99a8225d7a89455aa3a00026524e42a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 1]: /images/20221024/5dd7112c436e489f9fd22f180e8abce9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 2]: /images/20221024/7bdda6e2c89e4ebfbd44cf782d926e18.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 3]: /images/20221024/bc1036819f2e4217b641dc0082d35a3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 4]: /images/20221024/dbc5a3593475418f80dd0b890dc4ee2c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 5]: /images/20221024/ae2186fad0724105b595511524414718.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 6]: /images/20221024/fff56cb1d274485da0c803d1449134fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 7]: /images/20221024/ea0f6e7b99a74d4eb9129736ae391f60.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 8]: /images/20221024/c71c28bb0f704c65a6f2712d3db77086.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 9]: /images/20221024/8184d962cbd84cbfa55fb60939f41df4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 10]: /images/20221024/bac8d151533e47f5b156d3063eb911db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 11]: /images/20221024/e6709507f108467eb12d89fb0a4c424d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 12]: /images/20221024/c24953a115f6420ca8a28147e4b86ffe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 13]: /images/20221024/c2a3e47622504e7c988f0dab9f79b3f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 14]: /images/20221024/388a72baf8c04ceebdee1ee729580dc9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 15]: /images/20221024/fe8c93e7184e47089b4d0ea6c7252b63.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nMTE3ODM4Nzg0OA_size_16_color_FFFFFF_t_70 16]: /images/20221024/28e3be103f3243fe83cfe67ad57361d7.png