Redis分布式集群实战（四）——Redis cluster高可用集群的搭建部署

ゝ一纸荒年。 2023-07-18 03:11 103阅读 0赞

### 文章目录 ###

*  一、redis集群之redis cluster
 *   *  1.1为什么要用Redis Cluster
     *  1.2数据分布
     *   *  1、 数据分布的目的
         *  2、 常用数据分布方式之顺序分布
         *  3、 常用数据分布方式之哈希分布(虚拟槽分区是Redis Cluster采用的分区方式)
 *  二、Redis Cluster基本架构
 *   *  2.1 结构特点
     *  2.2 节点分配
     *  2.3 Redis Cluster主从模式
 *  三、Redis Cluster搭建
 *  四、Redis cluster集群的故障迁移

在前面的文章中，我们介绍了redis的主从和哨兵两种集群方案，redis从3.0版本开始引入了redis-cluster(集群)。  
从 `主从-哨兵-集群`可以看到redis的不断完善； `主从复制`是最简单的节点同步方案，但无法自动故障转移。 `哨兵`可以同时管理多个主从同步方案同时也可以处理主从自动故障转移，通过配置多个哨兵节点可以解决单点网络故障问题，但是单个节点的性能压力问题无法解决。 **集群解决了前面两个方案的所有问题，下面我们就学习redis cluster。**

# 一、redis集群之redis cluster #

对于Redis集群方案有好多种，基本常用的就是`twemproxy`，`codis`，`redis cluster`这三种解决方案。**Redis Cluster是Redis官方提供的Redis集群功能**

## 1.1为什么要用Redis Cluster ##

除了`主从复制`无法自动故障转移和`哨兵`无法解决单个节点的性能压力问题外，还有数据量的增加，当现有服务器内存不能满足业务数据的需要时，单纯向服务器添加内存不能达到要求，此时就需要考虑分布式需求，把数据分布到不同服务器上，还有就是网络流量需求，当业务的流量已经超过服务器的网卡的上限值，就需要使用分布式来进行分流。

## 1.2数据分布 ##

### 1、 数据分布的目的 ###

全量数据，单机Redis节点无法满足要求，按照分区规则把数据分到若干个子集当中。

### 2、 常用数据分布方式之顺序分布 ###

顺序分布常用在`关系型数据库`的设计.  
比如：1到100个数字，要保存在3个节点上，按照`顺序`分区，把数据`平均分配`三个节点上,1号到33号数据保存到节点1上，34号到66号数据保存到节点2上，67号到100号数据保存到节点3上  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]

### 3、 常用数据分布方式之哈希分布(虚拟槽分区是Redis Cluster采用的分区方式) ###

例如1到100个数字，对每个数字进行`哈希运算`，然后`对每个数的哈希结果除以节点数进行取余`，余数为1则保存在第1个节点上，余数为2则保存在第2个节点上，余数为0则保存在第3个节点，这样可以保证数据被打散，同时保证数据分布的比较均匀

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]  
**哈希分布方式分为三个分区方式：**

*  节点取余分区：比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]  
    优点：客户端分片,配置简单：对数据进行哈希，然后取余  
    缺点：数据节点伸缩时，导致数据迁移,迁移数量和添加节点数据有关，建议翻倍扩容  
    节点取余分区方式有一个问题：即当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分布，节点取余分区方式建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。**数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据**
 *  一致性哈希分区: **原理**： 将所有的数据当做一个token环，token环中的数据范围是0到2的32次方,然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个范围内的数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]  
**对每一个key进行hash运算，被哈希后的结果在哪个token的范围内，则按顺时针去找最近的节点，这个key将会被保存在这个节点上。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]  
在下面的图中，有4个key被hash之后的值在在n1节点和n2节点之间，按照`顺时针`规则，这4个key都会被保存在n2节点上，  
**如果在n1节点和n2节点之间添加n5节点，当下次有key被hash之后的值在n1节点和n5节点之间，这些key就会被保存在n5节点上。**  
在此例子里，添加n5节点之后，数据迁移会在n1节点和n2节点之间进行，n3节点和n4节点不受影响，数据迁移范围被缩小很多，同理，如果有1000个节点，此时添加一个节点，受影响的节点范围最多只有千分之2。  
**一致性哈希一般用在节点比较多的时候**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]  
优点：采用客户端分片方式：哈希 + 顺时针(优化取余)；节点伸缩时，只影响邻近节点，但是还是有数据迁移  
缺点：翻倍伸缩

*  虚拟槽分区:预设`虚拟槽`，每个槽就相当于一个数字，有一定范围。每个槽映射一个数据子集，一般比节点数大。**Redis Cluster中预设虚拟槽的范围为0到16383**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]  
**步骤：**

1.把16384槽按照节点数量进行平均分配，由节点进行管理
    2.对每个key按照CRC16规则进行hash运算
    3.把hash结果对16383进行取余
    4.把余数发送给Redis节点
    5.节点接收到数据，验证是否在自己管理的槽编号的范围
        如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果
        如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中

需要注意的是：Redis Cluster的节点之间会`共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽`  
**虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。当节点扩容或者缩容时，对数据槽进行重新分配迁移即可**，`数据不会丢失`。  
**虚拟槽分区特点:** 使用服务端管理节点，槽，数据：例如Redis Cluster；可以对数据打散，又可以保证数据分布均匀

# 二、Redis Cluster基本架构 #

Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。其redis-cluster架构图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]  
图中描述的是六个redis实例构成的集群

*  6379端口为客户端通讯端口
 *  16379端口为集群总线端口

**集群内部划分为16384个数据分槽，分布在三个主redis中。  
从redis中没有分槽，不会参与集群投票，也不会帮忙加快读取数据，仅仅作为主机的备份。**

三个主节点中平均分布着16384数据分槽的三分之一，每个节点中不会存有有重复数据，仅仅有自己的从机帮忙冗余。

## 2.1 结构特点 ##

1、所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。

2、节点的fail是通过集群中超过半数的节点检测失效时才生效，只有当集群中的过半节点同时fail整个集群才fail。  
3、客户端与redis节点直连，不需要中间proxy层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。  
4、redis-cluster把所有的物理节点映射到\[0-16383\]slot上，cluster 负责维护node<->slot<->value。  
5、Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod16384的值，决定将一个key放到哪个桶中。

## 2.2 节点分配 ##

假设我们现在有三个主节点，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽  
(hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

> 节点A覆盖0－5460；  
> 节点B覆盖5461－10922；  
> 节点C覆盖10923－16383

获取数据：

如果存入一个值，按照redis cluster哈希槽的算法： CRC16(‘key’)%16384 = 6782。  
那么就会把这个key 的存储分配到 B  
上了。同样，当我连接(A，B，C)任何一个节点想获取’key’这个key时，也会这样的算法，然后内部跳转到B节点上获取数据。

新增一个主节点：  
新增一个节点D，redis  
cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：

节点A覆盖1365-5460
    节点B覆盖6827-10922
    节点C覆盖12288-16383
    节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

## 2.3 Redis Cluster主从模式 ##

为了保证数据的高可用性，加入了主从模式，`一个主节点对应一个或多个从节点`，主节点提供数据存取，从节点则是从主节点拉取数据备份，\`当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

上面那个例子里，集群有ABC三个主节点,如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法访问整个集群了。A和C的slot也无法访问。
    
     所以我们在集群建立的时候，一定要为每个主节点都添加了从节点， 比如像这样,集群包含主节点A、B、C,，以及从节点A1、B1、C1，那么即使B挂掉系统也可以继续正确工作。
    
     B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服务。 当B重新开启后，它就会变成B1的从节点。
    
    不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了。
    `

# 三、Redis Cluster搭建 #

**节点准备（官方推荐三主三从的配置方式。）**  
redis3.0及以上版本实现，集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。

**实验步骤如下所示：**

1、设置`overcommit_memory`为1

*  `/proc/sys/vm/overcommit_memory`，是一个内核对内存分配的一种策略。`overcommit_memory`取值又三种分别为`0，1， 2`。`0`，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。`1`， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。`2，` 表示内核允许分配超过所有物理内存和交换空间总和的内存。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]  
    2、停掉redis服务（redis服务本身监听的端口是`6379`端口），创建目录，用于存放redis Cluster对应的节点配置文件

[root@server1 ~]# /etc/init.d/redis_6379 stop
    [root@server1 ~]# mkdir /usr/local/rediscluster
    [root@server1 ~]# cd /usr/local/rediscluster/
    [root@server1 rediscluster]# mkdir 700{ 1..6}
    [root@server1 rediscluster]# ls
    7001  7002  7003  7004  7005  7006

![在这里插入图片描述][20200323220802868.png]  
3、编写redis Cluster对应的节点的配置文件，并启动redis Cluster对应的所有节点，下面给出的是一个节点7001的配置文件（其余节点的配置文件跟这个配置文件类似，只需要将其中的7001改为对应的节点即可）

[root@server1 rediscluster]# cd 7001/
    [root@server1 7001]# vim redis.conf
    
     port 7001                    
     		#端口
     cluster-enabled yes          
     		#如果是yes，表示启用集群，否则以单例模式启动
     cluster-config-file nodes.conf     
     		#请注意，尽管有此选项的名称，但这不是用户可编辑的配置文件，而是Redis群集节点每次发生更改时自动保留群集配置（基本上为状态）的文件，以便能够 在启动时重新读取它。 该文件列出了群集中其他节点，它们的状态，持久变量等等。 由于某些消息的接收，通常会将此文件重写并刷新到磁盘上。
     cluster-node-timeout 5000     
     		#Redis群集节点超过不可用的最长时间，而会将其视为失败。 如果主节点超过指定的时间不可达，它将由其从属设备进行故障切换。 此参数控制Redis群集中的其他重要事项。 值得注意的是，每个无法在指定时间内到达大多数主节点的节点将停止接受查询。
     appendonly yes     
     		#是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。
     daemonize yes        
     		#打入后台，否则会占用我们的终端
    
    [root@server1 7001]# redis-server redis.conf   #启动7001节点 
    [root@server1 7001]# netstat -antlp | grep 7001

![在这里插入图片描述][20200323221001973.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]  
在其余目录里面也是一样的操作，记得对应的目录就是文件里面写的端口。（例如7002目录下的配置文件中相应的号就是7002

cp redis.conf ../7002
     cp redis.conf ../7003
     cp redis.conf ../7004
     cp redis.conf ../7005  
     cp redis.conf ../7006

![在这里插入图片描述][20200323221100870.png]  
**在7002目录下：**  
![在这里插入图片描述][20200323221118354.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]  
**在7003目录下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]  
**在7004目录下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 13]  
**在7005和7006目录下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 14]  
查看所有端口：

ps aux | grep 700*

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

redis-cli -p 7001
    127.0.0.1:7001> info
    
    # Cluster	
    cluster_enabled:1	#表示集群状态是激活的

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

4、创建集群（集群中的主从节点是随机的），节点全部启动后，每个节点目前只能识别出自己的节点信息，彼此之间并不知道对方的存在；实现集群的快速搭建，需要使用`redis-cluster`来创建集群

cd redis-5.0.3/
    cd src
    cp redis-trib.rb /usr/local/bin
    
    redis-trib.rb	#官网提供的命令
    /usr/bin/env: ruby: No such file or directory
    yum install ruby -y
    redis-trib.rb 
    redis-cli --cluster help	#根据提示创建集群
    
    redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7001 127.0.0.1:7002 
    127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006	#创建集群

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 17]  
创建成功：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 18]

5、我们可以使用下面的命令，来`查看集群的主节点信息`等

redis-cli --cluster info 127.0.0.1:7001	#查看集群信息

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 19]  
此时7001 7002 7003作为master，并且每个都有一个slave

用下面这个命令查看该`集群`的具体信息

redis-cli --cluster check 127.0.0.1:7001

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 20]  
6、测试存取值：无中心检测  
**客户端连接集群redis-cli需要带上 -c**

redis-cli -c -p　　７００１

![在这里插入图片描述][20200323222826648.png]  
我们在7004节点获取name值，也是跳转到7002  
![在这里插入图片描述][20200323222842870.png]  
但是，在7002节点获取name值，就不会跳转，因为本来就存储在7002节点。  
![在这里插入图片描述][20200323222856605.png]

# 四、Redis cluster集群的故障迁移 #

**1、模拟节点7002挂掉：宕掉一个master，会有它的slave来接替：**

redis-cli -c -p 7005
    127.0.0.1:7005> get name
    -> Redirected to slot [5798] located at 127.0.0.1:7002	#自动跳转到7002上
    "nigar"
    127.0.0.1:7002> SHUTDOWN	#宕掉7002
    not connected>

![在这里插入图片描述][20200323223049272.png]  
![在这里插入图片描述][20200323223036914.png]  
**2、查看集群的信息，可以看到7004节点，接替7002为新的主节点。**  
![在这里插入图片描述][20200323223106863.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 21]  
7004作为新的master来顶替7002

此时，我们在节点7001，获取name值，自动跳转到7004节点，仍可以获取name值，服务不受任何影响。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 22]  
**3、此时，如果将7004节点也手动down掉，那么该集群也就费了，因为至少三个master。**

redis-cli -c -p 7001
    127.0.0.1:7001> get name
    -> Redirected to slot [5798] located at 127.0.0.1:7004	#自动跳转到7004上
    "nigar"
    127.0.0.1:7004> SHUTDOWN	#宕掉7004

此时查看集群信息：

redis-cli --cluster info 127.0.0.1:7004

也读不到name信息了：

redis-cli -c -p 7001
    127.0.0.1:7001> get name
    (error) CLUSTERDOWN The cluster is down

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 23]  
**4、那如何恢复数据呢？我们进入7004的目录，可以查看数据文件。**

重新加载7002和7004的配置文件：

cd /usr/local/rediscluster/
    cd 7002
    cat appendonly.aof	#其中存储了之前的数据
    redis-server redis.conf 
    ps aux | grep redis-server

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 24]  
7004做法相同  
查看集群的主节点信息，看到集群已经恢复。

redis-cli --cluster info 127.0.0.1:7001

![在这里插入图片描述][20200323223810704.png]  
此时7001 7003 7004作为master

登录7001获取name值，可以获取到，会跳转到7004，只要数据文件没有丢失，我们恢复好master后，依旧可以看到数据。

redis-cli -c -p 7001
    127.0.0.1:7001> get name
    -> Redirected to slot [5798] located at 127.0.0.1:7004
    "ranran"

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]: /images/20230528/948c00ccb31648c382cb30abf60d5c24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/a5c7c644a40e4e7d9dcf2fa9b4ff124a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]: /images/20230528/e9d97915589041c7ba7429ea81e201d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]: /images/20230528/2171fc3145f1430fa0ad5e76a3ecec19.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]: /images/20230528/99e0981bd95543509cc67daa1a43a7cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]: /images/20230528/a1f4a762668f4d968cb9b60900ef07e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]: /images/20230528/ee0167b449804d1a836eef184e8df897.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]: /images/20230528/21f1ceec2a6246e9b04008306c0bb160.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]: /images/20230528/d436e394b5274e3cafc7d459ee96d0aa.png
[20200323220802868.png]: /images/20230528/ab5d40363c15425497c800200109686d.png
[20200323221001973.png]: /images/20230528/363f943f3a014eafb076857dbab5c21d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]: /images/20230528/0b31e0e94fa64329b004f1c8af649326.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]: /images/20230528/35504c4ffdf749049bc587de9d70a96e.png
[20200323221100870.png]: /images/20230528/eec2f5d9ecbd4921a3a2914bb18e5341.png
[20200323221118354.png]: /images/20230528/773f7d7220db4df1ad183f9ea9528147.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]: /images/20230528/ddcb791c9c7f438990d55d6961b284b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]: /images/20230528/aa79406d79314eca8d1c929ddbf135f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 13]: /images/20230528/977e09cd97ad435b92ac2b7cb5bcadcb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 14]: /images/20230528/95a007ce2e0546868fbbe941d5efb23c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 15]: /images/20230528/2bda83a48e3a4328b3daa43d6a9e6bf3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 16]: /images/20230528/9078c24f1e284556bde6eb3fc8d075bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 17]: /images/20230528/299c7c147320449eb0193e1737155ea7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 18]: /images/20230528/b0985aee7f334f3ea0b2eaa677f31dbb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 19]: /images/20230528/409e9e18a90046e5b00fcf88ae02d520.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 20]: /images/20230528/01de27e556b54d2189c44e818bbbc687.png
[20200323222826648.png]: /images/20230528/2398f9d85de948e0aca91a150819d83b.png
[20200323222842870.png]: /images/20230528/fcc99260d790425e9039eb53f8a9d2dc.png
[20200323222856605.png]: /images/20230528/67b0574d0d9a45b6afb27ed4f17ddbee.png
[20200323223049272.png]: /images/20230528/f65a89d56be74023903d84b66b199e64.png
[20200323223036914.png]: /images/20230528/47975414706c43feb181f5d9f94dcc86.png
[20200323223106863.png]: /images/20230528/a50bf69b0a0742aea09285da4b1a08e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 21]: /images/20230528/c298732597fb4fa88719d5f346c4782b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 22]: /images/20230528/7cd6c86c10a8496cbccd6655b15fe672.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 23]: /images/20230528/859327b347664f5a8ab587e22603851e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 24]: /images/20230528/c527c9b666514c2ca1920e2b8211d825.png
[20200323223810704.png]: /images/20230528/084e92cdd3f74a9eb57c1a77fba86c3f.png
[20200323223916406.png]: /images/20230528/69e96ff6abb9482d95f26b2c89c5a939.png