redis：客户端管理

素颜马尾好姑娘i 2022-09-15 12:21 304阅读 0赞

# 机制 #

redis提供了一些操作客户端的命令，比如查询所有已连接到服务端的客户端数量，控制客户端的连接状态（关闭或者挂起）等。通过客户命令我们可以轻松实现对客户端的管理、控制。

redis服务器通过**监听TCP端口的方式来接收客户端连接**。当一个连接建立后，redis会自动执行以下过程：

*  首先客户端socket被设置为非阻塞模式，这是因为redis在网络事件处理上采用了非阻塞IO（即IO多路复用模型）
 *  其次设置socket的TCP\_NODELAY属性，从而禁用Nagle算法
 *  最后创建一个可读的文件事件，用它来监听客户端socket的数据发送

redis使用命令的格式向客户端输入数据，这个数据量是非常小的。

*  当向客户端输入命令后，我们希望能够快速的得到服务器的应答，也就是低延迟性，但是如果开启了nagle算法就会出现频繁延时的现象，导致用户体验差。
 *  nagle算法可以提高广域网传输效率，减少分组的报文个数，适合传输体量较大的数据

> redis IO多路复用

redis的底层是一个单线程模型，单线程指的是用一个线程来处理所有的网络事件请求，这样就避免了多进程或者多线程切换导致的CPU消耗，而且也不用考虑各种锁的问题。

redis为了充分利用单线程，加快服务器的处理速度，它采用IO多路复用模型来处理客户端与服务端的连接，这种模型有三种实现方式：select、poll、epoll。在Linux系统上，redis会采用epoll的方式来监控多个IO事件。当客户端空闲时，线程处于阻塞状态；当一个或者多个IO事件触发时（客户端发起网络连接请求），线程就会从阻塞状态唤醒，并同时使用`epoll`来轮询触发事件，并同时使用epoll来轮询触发事件，并依次提交给线程处理。

“多路”指的是多个网络连接，“复用”指的是复用同一个线程。多路 IO 复用技术可以让单个线程高效的处理多个连接请求

# 客户端API #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CLIENT LIST</td> 
   <td>以列表的形式返回所有连接到 Redis 服务器的客户端。</td> 
  </tr> 
  <tr> 
   <td>CLIENT SETNAME</td> 
   <td>设置当前连接的名称。</td> 
  </tr> 
  <tr> 
   <td>CLIENT GETNAME</td> 
   <td>获取通过 CLIENT SETNAME 命令设置的服务名称。</td> 
  </tr> 
  <tr> 
   <td>CLIENT PAUSE</td> 
   <td>挂起客户端连接，将所有客户端挂起指定的时间（以毫秒为计算）</td> 
  </tr> 
  <tr> 
   <td>CLIENT KILL</td> 
   <td>关闭客户端连接。</td> 
  </tr> 
  <tr> 
   <td>CLIENT ID</td> 
   <td>返回当前客户端 ID。</td> 
  </tr> 
  <tr> 
   <td>CLIENT REPLY</td> 
   <td>控制发送到当前连接的回复，可选值包括 on</td> 
  </tr> 
 </tbody> 
</table>

## CLIENT ID ##

127.0.0.1:6379> CLIENT ID
    (integer) 2557

## Client List ##

### 作用 ###

*  client list命令能列出与Redis服务端相连的所有客户端连接信息

### 语法 ###

redis 127.0.0.1:6379> CLIENT LIST

### 实例 ###

redis 127.0.0.1:6379> CLIENT LIST
    addr=127.0.0.1:43143 fd=6 age=183 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
    addr=127.0.0.1:43163 fd=5 age=35 idle=15 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
    addr=127.0.0.1:43167 fd=7 age=24 idle=6 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

### 返回值 ###

命令返回多行字符串，这些字符串按以下形式被格式化：

*  每个已连接客户端对应一行（以 LF 分割）
 *  每行字符串由一系列 属性=值 形式的域组成，每个域之间以空格分开

#### 标识：id、addr、fd、name ####

*  ·id：客户端连接的唯一标识，这个id是随着Redis的连接自增的，重启 Redis后会重置为0。
 *  addr：客户端连接的ip和端口。
 *  ·fd：socket的文件描述符，与lsof命令结果中的fd是同一个，如果fd=-1 代表当前客户端不是外部客户端，而是Redis内部的伪装客户端。
 *  name：客户端的名字，后面的client setName和client getName两个命令会对其进行说明。

#### 输入缓冲区：qbuf、qbuf-free ####

*  redis为每个客户端分配了输入缓冲区，它的作用是将客户端发送的命令临时保存，同时redis会从输入缓冲区拉取命令并执行，输入缓冲区为客户端发送命令到redis服务端提供了缓存功能
 *  client list中qbuf和qbuf-free分别代表这个缓冲区的总容量和剩余容量
    
     *  qbuf ： 查询缓冲区的长度（字节为单位， 0 表示没有分配查询缓冲区）
     *  qbuf-free ： 查询缓冲区剩余空间的长度（字节为单位， 0 表示没有剩余空间）
 *  redis没有提供相应的配置来规定每个缓冲区的大小，输入缓冲区会根据输入内容的大小的不同动态调整，**只是要求每个客户端缓冲区的大小不能超过1G（源码中写死的），超过后客户端将关闭**

/* Protocol and I/O related defines */
    #define REDIS_MAX_QUERYBUF_LEN (1024*1024*1024) /* 1GB max query buffer. */

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]  
输入缓冲区使用不当会产生两个问题：

*  一旦某个客户端的输入缓冲区超过1G，客户端将别关闭
 *  输入缓冲区不受maxmemory控制，假设一个redis实例设置了maxmemory为4G，已经存储了2G的数据，但是此时输入缓冲区使用了3G，超过了maxmeory限制，可能会产生数据丢失，键值淘汰  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]

输入缓冲区使用不当造成的危害非常大，那么**造成输入 缓冲区过大的原因有哪些**？两个原因：

*  **输入缓冲区过大主要是因为redis的处理速度跟不上输入缓冲区的输入速度，并且每次进入输入缓冲区的命令包含了大量bigkey，从而造成了输入缓冲区过大的情况**
 *  **redis发生了阻塞，短期内不能处理命令，造成客户端输入的命令挤压在了输入缓冲区，造成了输入缓冲区过大**

那么**如何快速发现和监控呢**？两种方法：

*  通过定期执行client list命令，收集qbuf和qubf-free找到异常的连接记录并分析，最终找到可能出问题的客户端
 *  通过info命令的`info clients`模块，找到最大的输入缓冲区，比如下面命令中的其中`client_biggest_input_buf`代表最大的输入缓冲区，可以设置超过10M就进行报警  
    ![在这里插入图片描述][c16f9a6522da48cdb5a98b6007317406.png]

![在这里插入图片描述][5c67cede9816447b89bce36a0489bf00.png]  
运维提示：

*  输入缓冲区问题出现概率比较低，但是也要做好防范，在开发中要减少bigkey、减少Redis阻塞、合理的监控报警

#### 输出缓冲区：obl、oll、omem ####

Redis为每个客户端分配了输出缓冲区，它的作用是**保存命令执行的结 果返回给客户端，为Redis和客户端交互返回结果提供缓冲**。如下图：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
与输入缓冲区不同的是

*  输出缓冲区的容量可以通过参数`client-outputbuffer-limit`来进行设置；
 *  并且输出缓冲区做的更加细致，按照客户端的不同可以分为三种：普通客户端、发布订阅客户端、slave客户端，如下图：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
对应的配置规则是：

client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

*  `<class>`：客户端类型，分为三种。
    
     *  a）normal：普通客户端；
     *  b） slave：slave客户端，用于复制；
     *  c）pubsub：发布订阅客户端。
 *  `<hard limit>`：如果客户端使用的输出缓冲区大于，客户端会被立即关闭。
 *  ·`<soft limit>`和`<soft seconds>`：如果客户端使用的输出缓冲区超过了`<soft limit>`并且持续了`<soft limit>`秒，客户端会被立即关闭。

Redis的默认配置是：

[root@localhost ~]# grep -v '^#'  /usr/local/redis/6379.conf | grep buffer
    client-output-buffer-limit normal 0 0 0
    client-output-buffer-limit replica 256mb 64mb 60
    client-output-buffer-limit pubsub 32mb 8mb 60

与输入缓冲区一样，**输出缓冲区也不会受到maxmemory的限制，如果使用不当同样会造成maxmemory用满产生的数据丢失、键值淘汰、OOM等情况**

实际上输出缓冲区由两部分组成：

*  固定缓冲区（16KB）
 *  动态缓冲区

其中**固定缓冲区返回比较小的执行结果，而动态缓冲区返回比较大的执行结果**， 例如大的字符串、 hgetall、 smembers命令的结果等， 通过Redis源码中redis.h的redisClient结构体（Redis3.2版本变为Client） 可以看到两个缓冲区的实现细节：

typedef struct redisClient {
        
    // 动态缓冲区列表
    list *reply;
    // 动态缓冲区列表的长度(对象个数)
    unsigned long reply_bytes;
    // 固定缓冲区已经使用的字节数
    int bufpos;
    // 字节数组作为固定缓冲区
    char buf[REDIS_REPLY_CHUNK_BYTES];
    } redisClient;

**固定缓冲区使用的是字节数组，动态缓冲区使用的是列表。当固定缓冲区满之后会将redis新的返回结果存放在动态缓冲区的队列中，队列中的每个对象就是每个返回结果**，如下图  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
client list中的**obl代表固定缓冲区的长度，oll代表动态缓冲区列表的长度，omem代表使用的字节数**。例如下面代表当前客户端的固定缓冲区的长度为0， 动态缓冲区有4869个对象， 两个部分共使用了133081288字节=126M内存：

id=7 addr=127.0.0.1:56358 fd=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 multi=
    qbuf=0 qbuf-free=0 obl=0 oll=4869 omem=133081288 events=rw cmd=monitor

**监控输出缓冲区的方法**依然有两种：

*  通过定期执行client list命令，收集obl、 oll、 omem找到异常的连接记录并分析， 最终找到可能出问题的客户端。
 *  通过info命令的info clients模块，找到输出缓冲区列表最大对象数量， 其中， client\_longest\_output\_list代表输出缓冲区列表最大对象数。 比如：

127.0.0.1:6379> info clients
    # Clients
    connected_clients:502
    client_longest_output_list:4869
    client_biggest_input_buf:0
    blocked_clients:0

这两种统计方法的优劣势和输入缓冲区是一样的

相比于输入缓冲区，**输出缓冲区出现异常的概率相对比较大，那么如何预防呢**？方法如下

*  **进行上述监控，设置阈值，超过阈值即使处理**
 *  **限制普通客户端输出缓冲区的`<hard limit>、<soft limit>、<soft seconds>`，把错误扼杀在摇篮中**，比如：

client-output-buffer-limit normal 20mb 10mb 120

*  **适当增大slave的输出缓冲区的`<hard limit>、<soft limit>、<soft seconds>`，如果master节点写入较大，slave客户端的输出缓冲区可能会比较大，一旦slave客户端连接因为输出缓冲区溢出被kill，会造成复制重连**
 *  **限制容易让输出缓冲区增大的命令**，比如，高并发下的monitor命令就 是一个危险的命令
 *  **及时监控内存，一旦发现内存抖动频繁，可能就是输出缓冲区过大**

#### 客户端的存活状态（age、idle） ####

*  client list中的age和idle分别代表：
    
     *  当前客户端已经连接的时间(单位是秒)
     *  最近一次的空闲时间(单位是秒)：

> 实例

例如下面这条记录代表当期客户端连接Redis的时间为603382秒，其中空闲了331060秒：

id=2232080 addr=10.16.xx.55:32886 fd=946 name= age=603382 idle=331060 flags=N db=0
    
    sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

下面这条记录代表当期客户端连接Redis的时间为8888581秒，其中空闲了8888581秒。实际上这种就属于**不太正常的情况**，**当age等于idle时， 说明连接一直处于空闲状态**

id=254487 addr=10.2.xx.234:60240 fd=1311 name= age=8888581 idle=8888581 flags=N db=0
    
    sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

> 演示

String key = "hello";
    // 1) 生成jedis，并执行get操作
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    System.out.println(jedis.get(key));
    // 2) 休息10秒
    TimeUnit.SECONDS.sleep(10);
    // 3) 执行新的操作ping
    System.out.println(jedis.ping());
    // 4) 休息5秒
    TimeUnit.SECONDS.sleep(5);
    // 5) 关闭jedis连接
    jedis.close();

下面对代码中的每一步进行分析，用client list命令来观察age和idle参数的相应变化

*  在执行代码之前，client list只有一个客户端，也就是当前的rediscli

127.0.0.1:6379> client list
    
    id=45 addr=127.0.0.1:55171 fd=6 name= age=2 idle=0 flags=N db=0 sub=0 psub=0
    
    multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

*  使用Jedis生成了一个新的连接，并执行get操作，可以看到IP地址为 10.7.40.98的客户端，最后执行的命令是get，age和idle分别是1秒和0秒

127.0.0.1:6379> client list
    id=46 addr=10.7.40.98:62908 fd=7 name= age=1 idle=0 flags=N db=0 sub=0 psub=0
    multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

*  休息10秒，此时Jedis客户端并没有关闭，所以age和idle一直在递 增

27.0.0.1:6379> client list
    id=46 addr=10.7.40.98:62908 fd=7 name= age=9 idle=9 flags=N db=0 sub=0 psub=0
    multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

*  执行新的操作ping，发现执行后age依然在增加，而idle从0计算，也 就是不再闲置

127.0.0.1:6379> client list
    id=46 addr=10.7.40.98:62908 fd=7 name= age=11 idle=0 flags=N db=0 sub=0 psub=0
    multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping

*  休息5秒，观察age和idle增加

127.0.0.1:6379> client list
    id=46 addr=10.7.40.98:62908 fd=7 name= age=15 idle=5 flags=N db=0 sub=0 psub=0
    multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping

*  关闭Jedis，Jedis连接已经消失

redis-cli client list | grep "10.7.40.98”为空

#### 客户端的限制maxclients和timeout ####

*  redis提供了maxclients参数来限制客户端的最大连接数，一旦连接数超过maxclients，新的连接将被拒绝。maxclients默认值是10000

可以通过info clients来查询当前Redis的连接数。

127.0.0.1:6379> info clients
    #Clients
    connected_clients:1414

可以通过config set maxclients对最大客户端连接数进行动态设置：

127.0.0.1:6379> config get maxclients
    1)"maxclients"
    2)"10000"
    127.0.0.1:6379> config set maxclients 50
    OK
    127.0.0.1:6379> config get maxclients
    1)"maxclients"
    2) "50"

*  一般来说maxclients=10000在大部分场景下已经绝对够用，但是某些情况由于业务方使用不当（例如没有主动关闭连接）可能存在大量idle连接，无论是从网络连接的成本还是超过maxclients的后果来说都不是什么好事，因此Redis提供了timeout（单位为秒）参数来限制连接的最大空闲时间，一旦客户端连接的idle时间超过了timeout，连接将会被关闭

# Redis默认的timeout是0，也就是不会检测客户端的空闲 
    127.0.0.1:6379> config set timeout 30  #设置timeout为30秒
    OK

#### 客户端类型（flag） ####

*  client list中的flag是用于标识当前客户端的类型

例如flag=S代表当前客 户端是slave客户端、flag=N代表当前是普通客户端，flag=O代表当前客户端 正在执行monitor命令。下图列出了11种客户端类型：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]

## client setName和client getName ##

> client setName

client setName xx

client setName用于给客户端设置名字，这样比较容易标识出客户端的来源。例如将当前客户端命名为test\_client，可以执行如下操作：

![在这里插入图片描述][ce68011eeb6045eea0e42921e245a031.png]  
此时再执行client list命令，就可以看到当前客户端的name属性为test\_client：

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

> client getName

client getName

如果想直接查看当前客户端的name，可以使用client getName命令

第一次进入客户端时，客户端是没有名字的，因此名字为空  
![在这里插入图片描述][43379ee8068644859039e94c6437e358.png]  
更改名字之后，就可以看到更改后的名字了。例如：  
![在这里插入图片描述][312fa668f0174004ab72df4799ab1df4.png]

用得少

## client kill ##

client kill ip:port

*  此命令用于杀掉指定IP地址和端口的客户端
 *  由于一些原因（例如设置timeout=0时产生的长时间idle的客户端），需要手动杀掉客户端连接时，可以使用client kill命令

如果想杀掉127.0.0.1：52343的客户端，可以执行：

127.0.0.1:6379> client kill 127.0.0.1:52343

## Client Pause ##

### 作用 ###

*  用于阻塞客户端timeout毫秒数，在此期间客户端连接将被阻塞

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

### 语法 ###

redis 127.0.0.1:6379> CLIENT PAUSE timeout

### 返回值 ###

*  返回 OK。如果 timeout 参数是非法的返回错误。

### 演示 ###

例如在一个客户端执行下面的命令，在之后的10000毫秒内的其他客户端连接都会被阻塞  
![在这里插入图片描述][3ad0e4352b634dcab62216f9f2e5a983.png]  
过一会后在另一个客户端执行ping命令，发现整个ping命令执行了2.40秒（手动执行redis-cli，只为了演示，不代表真实执行时间）：  
![在这里插入图片描述][e3e9524caa2043c3ab72fc84ae8cdc20.png]

## monitor ##

### 作用 ###

*  monitor命令用于监控Redis正在执行的命令

### 演示 ###

我们打开了两个redis-cli，右侧先执行monitor命令，左侧再执行其他命令

可以看到monitor命令能够监听其他客户端正在执行的命令，并记录了详细的时间戳

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

### 注意 ###

*  monitor的作用很明显，如果开发和运维人员想监听Redis正在执行的命令，就可以用monitor命令
 *  但事实并非如此美好，每个客户端都有自己的输出缓冲区，既然monitor能监听到所有的命令，一旦Redis的并发量过大， monitor客户端的输出缓冲会暴涨，可能瞬间会占用大量内存。

# 客户端相关配置 #

*  timeout：
    
     *  检测客户端空闲连接的超时时间
     *  一旦idle时间达到了timeout，客户端将会被关闭
     *  如果设置为0就不检测
 *  ·maxclients：客户端最大连接数
 *  tcp-keepalive：
    
     *  检查TCP连接活性的周期，默认值为0，也就是不进行检测
     *  如果需要设置，建议60，那么redis会每隔60s对它创建的TCP连接进行活性检测，防止大量死连接占用系统资源
 *  ·tcp-backlog
    
     *  TCP三次握手后，会将接受的连接放入队列中，tcpbacklog就是队列的大小，它在Redis中的默认值是511
     *  通常来讲这个参数不 需要调整，但是这个参数会受到操作系统的影响，例如在Linux操作系统 中，如果/proc/sys/net/core/somaxconn小于tcp-backlog，那么在Redis启动时会 看到如下日志，并建议将/proc/sys/net/core/somaxconn设置更大  
        ![在这里插入图片描述][3066f29c498b4941a879aaaebf26c6d0.png]  
        修改方法也非常简单，只需要执行如下命令：

echo 511 > /proc/sys/net/core/somaxconn

## 客户端最大连接数 ##

在 Redis 配置文件中，有一个maxclients的配置项，它指定了连接到 Redis 服务器的最大客户端数量。其默认值是 10000。配置项如下所示：

127.0.0.1:6379> config get maxclients
    1) "maxclients"
    2) "10000"
    #更改最大连接数量
    127.0.0.1:6379> config set maxclients 20000
    OK
    127.0.0.1:6379> config get maxclients
    1) "maxclients"
    2) "20000"

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/f84d2c59de7b43b5adfe9afb23ca482e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/cfe1723908f34d4fb21c010bffa3c59f.png
[c16f9a6522da48cdb5a98b6007317406.png]: /images/20220828/3ae5eafce81642ce9e0fca5b921a5e71.png
[5c67cede9816447b89bce36a0489bf00.png]: /images/20220828/87ef9a4c9a7747d99975a7be00e20b15.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/0ca77ab7e73f4ee1bbe967830f02bcde.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/79b234e1d2ee47258dda39b5eb232eeb.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/0e51b6fb16d040b0b7ff19404447dd91.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/c91be6882120494da683b9c257dbdfee.png
[ce68011eeb6045eea0e42921e245a031.png]: /images/20220828/3b007b2911ae46fc8749d73f53b6b292.png
[973087d72e50455d9b6dbb440029e893.png]: /images/20220828/81e5397a9a374574a09119a32f41a6d7.png
[43379ee8068644859039e94c6437e358.png]: /images/20220828/cfa3fa8539884a38ac300cc7606c0d2a.png
[312fa668f0174004ab72df4799ab1df4.png]: /images/20220828/dbcc4702731341f59de51a03a2291a37.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/b4eda07d7d3a409f803fd71a1bafcd13.png
[3ad0e4352b634dcab62216f9f2e5a983.png]: /images/20220828/f9ce48c5a4f6412fbb1eaa0bc31958d4.png
[e3e9524caa2043c3ab72fc84ae8cdc20.png]: /images/20220828/75f8373114fb40a2a46daffe67fd99ef.png
[27fb0d90f22f4c23934372e1280d9012.png]: /images/20220828/0ad26bf1baf0492da4565517081308a2.png
[3066f29c498b4941a879aaaebf26c6d0.png]: /images/20220828/a38a5c14367c44aabad63b73ed9178c9.png