Redis数据类型实现原理

ゝ一纸荒年。 2023-07-07 11:29 12阅读 0赞

# Redis数据类型实现原理 #

### 文章目录 ###

*  Redis数据类型实现原理
 *   *  对象的类型与编码
     *   *  1、type属性
         *  2、encoding 属性和 \*prt 指针
     *  字符串对象
     *   *  1、编码
         *  2、编码的转换
     *  列表对象
     *   *  1、编码
         *  2、编码转换
         *  3、数据结构quicklist
     *  哈希对象
     *   *  1、编码
         *  2、编码转换
     *  集合对象
     *   *  1、编码
         *  2、编码转换
     *  有序集合对象
     *   *  1、编码
         *  2、编码转换
     *  五大数据类型的应用场景

在Redis中，并没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，这些对象系统也就是前面说的五大数据类型，每一种数据类型都至少用到了一种数据结构。通过这五种不同类型的对象，Redis可以在执行命令之前，根据对象的类型判断一个对象是否可以执行给定的命令，而且可以针对不同的场景，为对象设置多种不同的数据结构，从而优化对象在不同场景下的使用效率。

## 对象的类型与编码 ##

Redis使用前面说的五大数据类型来表示键和值，每次在Redis数据库中创建一个键值对时，至少会创建两个对象，一个是键对象，一个是值对象，而Redis中的每个对象都是由 redisObject 结构来表示：

typedef struct redisObject{
        
         //类型
         unsigned type:4;
         //编码
         unsigned encoding:4;
         //指向底层数据结构的指针
         void *ptr;
         //引用计数
         int refcount;
         //记录最后一次被程序访问的时间
         unsigned lru:22;
    }robj

### 1、type属性 ###

对象的type属性记录了对象的类型，这个类型就是前面讲的五大数据类型：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70]  
可以通过如下命令来判断对象类型：

type key
    
    127.0.0.1:6379> set key abc
    OK
    127.0.0.1:6379> set key 123
    OK
    127.0.0.1:6379> object encoding key
    "int"
    127.0.0.1:6379> set key2 abc
    OK
    127.0.0.1:6379> lpush list1 1 2 3 4
    (integer) 4
    127.0.0.1:6379> lpush list2 a b c d
    (integer) 4
    127.0.0.1:6379> object encoding list1
    "quicklist"
    127.0.0.1:6379> object encoding list2
    "quicklist"
    127.0.0.1:6379> type list1
    list
    127.0.0.1:6379> type key
    string
    127.0.0.1:6379> type key2
    string
    127.0.0.1:6379>

`注意：在Redis中，键总是一个字符串对象，而值可以是字符串、列表、集合等对象，所以我们通常说的键为字符串键，表示的是这个键对应的值为字符串对象，我们说一个键为集合键时，表示的是这个键对应的值为集合对象。`

### 2、encoding 属性和 \*prt 指针 ###

对象的 prt 指针指向对象底层的数据结构，而数据结构由 encoding 属性来决定。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 1]  
而每种类型的对象都至少使用了两种不同的编码：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 2]  
可以通过如下命令查看值对象的编码：

OBJECT ENCODING    key
    
    127.0.0.1:6379> object encoding key
    "int"
    127.0.0.1:6379> object encoding key2
    "embstr"
    127.0.0.1:6379> object encoding list1
    "quicklist"
    127.0.0.1:6379> object encoding list2
    "quicklist"

--------------------

## 字符串对象 ##

字符串是Redis最基本的数据类型，不仅所有key都是字符串类型，其它几种数据类型构成的元素也是字符串。`注意字符串的长度不能超过512M。`

### 1、编码 ###

字符串对象的编码可以是int，raw或者embstr。

*  int 编码：保存的是可以用 long 类型表示的整数值。
 *  raw 编码：保存长度大于44字节的字符串（redis3.2版本之前是39字节，之后是44字节）。
 *  embstr 编码：保存长度小于44字节的字符串（redis3.2版本之前是39字节，之后是44字节）。

127.0.0.1:6379> set key abc
    OK
    127.0.0.1:6379> object encoding key
    "embstr"
    127.0.0.1:6379> set key1 123
    OK
    127.0.0.1:6379> object encoding key1
    "int"
    127.0.0.1:6379> set key2 123434950669809297addhfghkjlkjqoiruryqeutytyoxzmxnbnbkskdujqidgbskghaksjhgakjha
    OK
    127.0.0.1:6379> object encoding key2
    "raw"

由上可以看出，int 编码是用来保存整数值，raw编码是用来保存长字符串，而embstr是用来保存短字符串。其实 embstr 编码是专门用来保存短字符串的一种优化编码，raw 和 embstr 的区别：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 3]  
![在这里插入图片描述][20200223115601971.png]

embstr与raw都使用redisObject和sds保存数据，区别在于，embstr的使用只分配一次内存空间（因此redisObject和sds是连续的），而raw需要分配两次内存空间（分别为redisObject和sds分配空间）。因此与raw相比，embstr的好处在于创建时少分配一次空间，删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便。而embstr的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个redisObject和sds都需要重新分配空间，因此redis中的embstr实现为只读。

`Redis中对于浮点数类型也是作为字符串保存的，在需要的时候再将其转换成浮点数类型。`

### 2、编码的转换 ###

当 int 编码保存的值不再是整数，或大小超过了long的范围时，自动转化为raw。

对于 embstr 编码，由于 Redis 没有对其编写任何的修改程序（embstr 是只读的），在对embstr对象进行修改时，都会先转化为raw再进行修改，因此，只要是修改embstr对象，修改后的对象一定是raw的，无论是否达到了44个字节。

--------------------

## 列表对象 ##

list 列表，它是简单的字符串列表，按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或者尾部（右边），它的底层实际上是个链表结构。

### 1、编码 ###

列表对象的编码可以是 ziplist(压缩列表) 和 linkedlist(双端链表)。 关于链表和压缩列表的特性可以[这篇博客][Link 1]。

比如我们执行以下命令，创建一个 key = ‘numbers’，value = ‘1 three 5’ 的三个值的列表。

rpush numbers 1 "three" 5

ziplist 编码表示如下：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 4]  
linkedlist表示如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 5]

### 2、编码转换 ###

当同时满足下面两个条件时，使用ziplist（压缩列表）编码：

*  列表保存元素个数小于512个
 *  每个元素长度小于64字节

不能满足这两个条件的时候使用 linkedlist 编码。

上面两个条件可以在redis.conf 配置文件中的 list-max-ziplist-value选项和 list-max-ziplist-entries 选项进行配置。

### 3、数据结构quicklist ###

`Redis新版本对列表对象底层数据结果进行了改造，使用quicklist代替了ziplist和linkedlist`

127.0.0.1:6379> rpush key6 1
    (integer) 1
    127.0.0.1:6379> object encoding key6
    "quicklist"

quicklist是一个ziplist的双向链表（双向链表是由多个节点Node组成的）。也就是说quicklist的每个节点quicklistNode都是一个ziplist。ziplist本身也是一个能维持数据项先后顺序的列表（按插入位置），而且是一个各个数据项在内存上前后相邻的列表。

quicklist结果定义:

*  双向链表在表的两端进行push和pop操作十分的便节，但是它的内存开销比较大。
    
    首先，它在每个节点上除了要保存数据之外，还要额外保存两个指针；
    
    其次，双向链表的各个节点是单独的内存块，地址不连续，节点多了容易产生内存碎片。
 *  ziplist由于是一整块连续内存，所以存储效率很高。
    
    首先，它不利于修改操作，每次数据变动都会引发一次内存的realloc。
    
    其次，当ziplist长度很长的时候，一次realloc可能会导致大批量的数据拷贝，进一步降低性能。

Redis基于空间和时间的考虑，于是quicklist结合双向链表和ziplist的优点。

typedef struct quicklist {
        
        // 指向quicklist的头部
        quicklistNode *head;
        // 指向quicklist的尾部
        quicklistNode *tail;
        //所有ziplist中所有条目的总数
        unsigned long count;        
        //quicklistNodes数量
        unsigned int len;          
        // ziplist大小限定，由list-max-ziplist-size给定
        int fill : 16;             
        // 节点压缩深度设置，由list-compress-depth给定
        unsigned int compress : 16;
    } quicklist;
    
    typedef struct quicklistNode {
        
        // 指向上一个ziplist节点
        struct quicklistNode *prev;
        // 指向下一个ziplist节点
        struct quicklistNode *next;
        // 数据指针，如果没有被压缩，就指向ziplist结构，反之指向quicklistLZF结构
        unsigned char *zl;
        // 表示指向ziplist结构的总长度(内存占用长度)
        unsigned int sz;             /* ziplist size in bytes */
        unsigned int count : 16;     /* count of items in ziplist */
        unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
        // 预留字段，存放数据的方式，1--NONE，2--ziplist
        unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
       // 解压标记，当查看一个被压缩的数据时，需要暂时解压，标记此参数为1，之后再重新进行压缩
        unsigned int recompress : 1; /* was this node previous compressed? */
        unsigned int attempted_compress : 1; /* node can't compress; too small */
        // 扩展字段
        unsigned int extra : 10; /* more bits to steal for future usage */
    
    } quicklistNode;
    
    typedef struct quicklistLZF {
        
        // LZF压缩后占用的字节数
        unsigned int sz; /* LZF size in bytes*/
        // 柔性数组，存放压缩后的ziplist字节数组
        char compressed[];
    } quicklistLZF;

`quicklistNode 中sz，如果ziplist被压缩了，那么这个sz的值仍然是压缩前的ziplist大小。`

`从上述的定义中，我们了解到quicklist 在64位系统中占用32字节的空间，quicklistNode 是一个32字节的结构。`

配置文件中两个重要参数设置

list-max-ziplist-size
    
    list-compress-depth

**list-max-ziplist-size**

1、list-max-ziplist-size取值，可以取正值，也可以取负值。

当取正值的时候，表示按照数据项个数来限定每个quicklist节点上的ziplist长度。比如，当这个参数配置成5的时候，表示每个quicklist节点的ziplist最多包含5个数据项。

当取负值的时候，表示按照占用字节数来限定每个quicklist节点上的ziplist长度。这时，它只能取-1到-5这五个值，每个值含义如下：

*  \-5: 每个quicklist节点上的ziplist大小不能超过64 Kb。（注：1kb => 1024 bytes）
 *  \-4: 每个quicklist节点上的ziplist大小不能超过32 Kb。
 *  \-3: 每个quicklist节点上的ziplist大小不能超过16 Kb。
 *  \-2: 每个quicklist节点上的ziplist大小不能超过8 Kb。（-2是Redis给出的默认值）
 *  \-1: 每个quicklist节点上的ziplist大小不能超过4 Kb。

2、list-max-ziplist-size配置产生的原因？

*  每个quicklist节点上的ziplist越短，则内存碎片越多。内存碎片多了，有可能在内存中产生很多无法被利用的小碎片，从而降低存储效率。这种情况的极端是每个quicklist节点上的ziplist只包含一个数据项，这就蜕化成一个普通的双向链表了。
 *  每个quicklist节点上的ziplist越长，则为ziplist分配大块连续内存空间的难度就越大。有可能出现内存里有很多小块的空闲空间（它们加起来很多），但却找不到一块足够大的空闲空间分配给ziplist的情况。这同样会降低存储效率。这种情况的极端是整个quicklist只有一个节点，所有的数据项都分配在这仅有的一个节点的ziplist里面。这其实蜕化成一个ziplist了。

可见，一个quicklist节点上的ziplist要保持一个合理的长度。那到底多长合理呢？Redis提供了一个配置参数list-max-ziplist-size，就是为了让使用者可以来根据实际应用场景进行调整优化。

**list-compress-depth**

其表示一个quicklist两端不被压缩的节点个数。注：这里的节点个数是指quicklist双向链表的节点个数，而不是指ziplist里面的数据项个数。实际上，一个quicklist节点上的ziplist，如果被压缩，就是整体被压缩的。

1、list-compress-depth的取值：

*  0: 是个特殊值，表示都不压缩。这是Redis的默认值。
 *  1: 表示quicklist两端各有1个节点不压缩，中间的节点压缩。
 *  2: 表示quicklist两端各有2个节点不压缩，中间的节点压缩。
 *  3: 表示quicklist两端各有3个节点不压缩，中间的节点压缩。
 *  依此类推…

由于0是个特殊值，很容易看出quicklist的头节点和尾节点总是不被压缩的，以便于在表的两端进行快速存取。

2、list-compress-depth配置产生原因？

当表list存储大量数据的时候，最容易被访问的很可能是两端的数据，中间的数据被访问的频率比较低（访问起来性能也很低）。如果应用场景符合这个特点，那么list还提供了一个选项，能够把中间的数据节点进行压缩，从而进一步节省内存空间。Redis的配置参数list-compress-depth就是用来完成这个设置的。

--------------------

## 哈希对象 ##

哈希对象的键是一个字符串类型，值是一个键值对集合。

### 1、编码 ###

哈希对象的编码可以是 ziplist 或者 hashtable。

当使用ziplist，也就是压缩列表作为底层实现时，新增的键值对是保存到压缩列表的表尾。比如执行以下命令：

hset profile name "Tom"
    hset profile age 25
    hset profile career "Programmer"

如果使用ziplist，profile 存储如下：  
![在这里插入图片描述][20200223115807589.png]

当使用 hashtable 编码时，上面命令存储如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 6]  
hashtable 编码的哈希表对象底层使用字典数据结构，哈希对象中的每个键值对都使用一个字典键值对。

在前面介绍压缩列表时，我们介绍过压缩列表是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，相对于字典数据结构，压缩列表用于元素个数少、元素长度小的场景。其优势在于集中存储，节省空间。

### 2、编码转换 ###

和上面列表对象使用 ziplist 编码一样，当同时满足下面两个条件时，使用ziplist（压缩列表）编码：

`列表保存元素个数小于512个`

`每个元素长度小于64字节`

不能满足这两个条件的时候使用 hashtable 编码。第一个条件可以通过配置文件中的 set-max-intset-entries 进行修改。

127.0.0.1:6379> hset key5 name tom
    (integer) 1
    127.0.0.1:6379> object encoding key5
    "ziplist"

--------------------

## 集合对象 ##

`集合对象 set 是 string 类型（整数也会转换成string类型进行存储）的无序集合。`注意集合和列表的区别：集合中的元素是无序的，因此不能通过索引来操作元素；`集合中的元素不能有重复。`

### 1、编码 ###

集合对象的编码可以是 intset 或者 hashtable。

intset 编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合中。

hashtable 编码的集合对象使用 字典作为底层实现，`字典的每个键都是一个字符串对象，这里的每个字符串对象就是一个集合中的元素，而字典的值则全部设置为 null。`这里可以类比Java集合中HashSet 集合的实现，HashSet 集合是由 HashMap 来实现的，集合中的元素就是 HashMap 的key，而 HashMap 的值都设为 null。

SADD numbers 1 3 5

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

SADD Dfruits "apple" "banana" "cherry"

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

127.0.0.1:6379> sadd k1 1 2 3
    (integer) 3
    127.0.0.1:6379> object encoding k1
    "intset"
    127.0.0.1:6379> sadd k2 a b c
    (integer) 3
    127.0.0.1:6379> object encoding k2
    "hashtable"

### 2、编码转换 ###

当集合同时满足以下两个条件时，使用 intset 编码：

*  集合对象中所有元素都是整数
 *  集合对象所有元素数量不超过512

不能满足这两个条件的就使用 hashtable 编码。第二个条件可以通过配置文件的 set-max-intset-entries 进行配置。

--------------------

## 有序集合对象 ##

和上面的集合对象相比，有序集合对象是有序的。与列表使用索引下标作为排序依据不同，有序集合为每个元素设置一个分数（score）作为排序依据。

### 1、编码 ###

有序集合的编码可以是 ziplist 或者 skiplist。

ziplist 编码的有序集合对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个节点保存元素的分值。并且压缩列表内的集合元素按分值从小到大的顺序进行排列，小的放置在靠近表头的位置，大的放置在靠近表尾的位置。

ZADD price 8.5 apple 5.0 banana 6.0 cherry

127.0.0.1:6379> ZADD price 8.5 apple 5.0 banana 6.0 cherry
    (integer) 3
    127.0.0.1:6379> zrange price  0 -1
    1) "banana"
    2) "cherry"
    3) "apple"
    127.0.0.1:6379> object encoding price
    "ziplist"
    127.0.0.1:6379>

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

skiplist 编码的有序集合对象使用 zet 结构作为底层实现，一个 zset 结构同时包含一个字典和一个跳跃表：

typedef struct zset{
        
         //跳跃表
         zskiplist *zsl;
         //字典
         dict *dice;
    } zset;

字典的键保存元素的值，字典的值则保存元素的分值；跳跃表节点的 object 属性保存元素的成员，跳跃表节点的 score 属性保存元素的分值。

这两种数据结构会通过指针来共享相同元素的成员和分值，所以不会产生重复成员和分值，造成内存的浪费。

说明：其实有序集合单独使用字典或跳跃表其中一种数据结构都可以实现，但是这里使用两种数据结构组合起来，原因是假如我们单独使用字典，虽然能以 O(1) 的时间复杂度查找成员的分值，但是因为字典是以无序的方式来保存集合元素，所以每次进行范围操作的时候都要进行排序；假如我们单独使用跳跃表来实现，虽然能执行范围操作，但是查找操作有 O(1)的复杂度变为了O(logN)。因此Redis使用了两种数据结构来共同实现有序集合。

### 2、编码转换 ###

当有序集合对象同时满足以下两个条件时，对象使用 ziplist 编码：

*  保存的元素数量小于128；
 *  保存的所有元素长度都小于64字节。

不能满足上面两个条件的使用 skiplist 编码。以上两个条件也可以通过Redis配置文件zset-max-ziplist-entries 选项和 zset-max-ziplist-value 进行修改。

--------------------

## 五大数据类型的应用场景 ##

1.  对于string 数据类型，因为string 类型是二进制安全的，可以用来存放图片，视频等内容，另外由于Redis的高性能读写功能，而string类型的value也可以是数字，可以用作计数器（INCR,DECR），比如分布式环境中统计系统的在线人数，秒杀等。
2.  对于 hash 数据类型，value 存放的是键值对，比如可以做单点登录存放用户信息。
3.  对于 list 数据类型，可以实现简单的消息队列，另外可以利用lrange命令，做基于redis的分页功能
4.  对于 set 数据类型，由于底层是字典实现的，查找元素特别快，另外set 数据类型不允许重复，利用这两个特性我们可以进行全局去重，比如在用户注册模块，判断用户名是否注册；另外就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。
5.  对于 zset 数据类型，有序的集合，可以做范围查找，排行榜应用，取 TOP N 操作等。

> 转载：https://www.cnblogs.com/ysocean/p/9102811.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200223114945209.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200223115018534.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200223115043871.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2020022311554630.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[20200223115601971.png]: https://img-blog.csdnimg.cn/20200223115601971.png
[Link 1]: https://www.cnblogs.com/ysocean/p/9080942.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200223115653128.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200223115711924.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[20200223115807589.png]: https://img-blog.csdnimg.cn/20200223115807589.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200223115822381.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200223115849118.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20200223115906904.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA==,size_16,color_FFFFFF,t_70
[20200223115951738.png]: https://img-blog.csdnimg.cn/20200223115951738.png