Redis几种底层数据结构(SDS IntSet Dict ZipList QuickList SkipList)

你的名字 2024-03-22 12:41 36阅读 0赞

#### 文章目录 ####

*   *  1 Redis数据结构-动态字符串SDS
     *  2 Redis数据结构-intset
     *  3 Redis数据结构-Dict
     *   *  Dict的扩容
         *  Dict的收缩
         *  Dict的rehash
     *  4 Redis数据结构-ZipList
     *   *  ZipListEntry
         *  Encoding编码
     *  5 Redis数据结构-ZipList的连锁更新问题
     *  6 Redis数据结构-QuickList
     *  7 Redis数据结构-SkipList
     *  8 Redis数据结构-RedisObject

### 1 Redis数据结构-动态字符串SDS ###

我们都知道Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。

不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题：

*  获取字符串长度的需要通过运算
 *  非二进制安全
 *  不可修改

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。  
例如，我们执行命令：

![1653984583289][]

那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“虎哥”的SDS。

Redis是C语言实现的，其中SDS是一个结构体，源码如下：

![1653984624671][]

例如，一个包含字符串“name”的sds结构如下：

![1653984648404][]

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为“hi”的SDS：

![1653984787383][]

假如我们要给SDS追加一段字符串“,Amy”，这里首先会申请新内存空间：

如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1；

如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

![1653984822363][]

![1653984838306][]

### 2 Redis数据结构-intset ###

IntSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。

结构如下：

![1653984923322][]

其中的encoding包含三种模式，表示存储的整数大小不同：

![1653984942385][]

为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：

![1653985149557][]

现在，数组中每个数字都在int16\_t的范围内，因此采用的编码方式是INTSET\_ENC\_INT16，每部分占用的字节大小为：  
encoding：4字节  
length：4字节  
contents：2字节 \* 3 = 6字节

![1653985197214][]

我们向该其中添加一个数字：50000，这个数字超出了int16\_t的范围，intset会自动升级编码方式到合适的大小。  
以当前案例来说流程如下：

*  升级编码为INTSET\_ENC\_INT32, 每个整数占4字节，并按照新的编码方式及元素个数扩容数组
 *  倒序依次将数组中的元素拷贝到扩容后的正确位置
 *  将待添加的元素放入数组末尾
 *  最后，将inset的encoding属性改为INTSET\_ENC\_INT32，将length属性改为4

![1653985276621][]

源码如下：

![1653985304075][]

![1653985327653][]

小总结：

Intset可以看做是特殊的整数数组，具备一些特点：

*  Redis会确保Intset中的元素唯一、有序
 *  具备类型升级机制，可以节省内存空间
 *  底层采用二分查找方式来查询

### 3 Redis数据结构-Dict ###

我们知道Redis是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。  
Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

![1653985396560][]

当我们向Dict添加键值对时，Redis首先根据key计算出hash值（h），然后利用 `h & sizemask`来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。

![1653985497735][]

Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

![1653985570612][]

![1653985586543][]

![1653985640422][]

#### Dict的扩容 ####

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。  
Dict在每次新增键值对时都会检查负载因子（LoadFactor = used/size） ，满足以下两种情况时会触发哈希表扩容：  
哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程；  
哈希表的 LoadFactor > 5 ；

![1653985716275][]

#### Dict的收缩 ####

Dict除了扩容以外，每次删除元素时，也会对负载因子做检查，当loadFactor<0.1时，会做哈希表收缩。

![1653985743412][]

#### Dict的rehash ####

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为rehash。过程是这样的：

*  计算新hash表的realSize，值取决于当前要做的是扩容还是收缩：
    
     *  如果是扩容，则新size为第一个大于等于dict.ht\[0\].used + 1的 2 n 2^n 2n
     *  如果是收缩，则新size为第一个大于等于dict.ht\[0\].used的 2 n 2^n 2n （不得小于4）
 *  按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht\[1\]
 *  设置dict.rehashidx = 0，标示开始rehash
 *  将dict.ht\[0\]中的每一个dictEntry都rehash到dict.ht\[1\]
 *  将dict.ht\[1\]赋值给dict.ht\[0\]，给dict.ht\[1\]初始化为空哈希表，释放原来的dict.ht\[0\]的内存
 *  将rehashidx赋值为-1，代表rehash结束
 *  在rehash过程中，新增操作，则直接写入ht\[1\]，查询、修改和删除则会在dict.ht\[0\]和dict.ht\[1\]依次查找并执行。这样可以确保ht\[0\]的数据只减不增，随着rehash最终为空

整个过程可以描述成：

![1653985824540][]

小总结：

Dict的结构：

*  类似java的HashTable，底层是数组加链表来解决哈希冲突
 *  Dict包含两个哈希表，ht\[0\]平常用，ht\[1\]用来rehash

Dict的伸缩：

*  当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容
 *  当LoadFactor小于0.1时，Dict收缩
 *  扩容大小为第一个大于等于used + 1的2^n
 *  收缩大小为第一个大于等于used 的2^n
 *  Dict采用渐进式rehash，每次访问Dict时执行一次rehash
 *  rehash时ht\[0\]只减不增，新增操作只在ht\[1\]执行，其它操作在两个哈希表

### 4 Redis数据结构-ZipList ###

ZipList 是一种特殊的“双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。

![1653985987327][]

![1653986020491][]

<table> 
 <thead> 
  <tr> 
   <th><strong>属性</strong></th> 
   <th><strong>类型</strong></th> 
   <th><strong>长度</strong></th> 
   <th><strong>用途</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>zlbytes</td> 
   <td>uint32_t</td> 
   <td>4 字节</td> 
   <td>记录整个压缩列表占用的内存字节数</td> 
  </tr> 
  <tr> 
   <td>zltail</td> 
   <td>uint32_t</td> 
   <td>4 字节</td> 
   <td>记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。</td> 
  </tr> 
  <tr> 
   <td>zllen</td> 
   <td>uint16_t</td> 
   <td>2 字节</td> 
   <td>记录了压缩列表包含的节点数量。 最大值为UINT16_MAX （65534），如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。</td> 
  </tr> 
  <tr> 
   <td>entry</td> 
   <td>列表节点</td> 
   <td>不定</td> 
   <td>压缩列表包含的各个节点，节点的长度由节点保存的内容决定。</td> 
  </tr> 
  <tr> 
   <td>zlend</td> 
   <td>uint8_t</td> 
   <td>1 字节</td> 
   <td>特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。</td> 
  </tr> 
 </tbody> 
</table>

#### ZipListEntry ####

ZipList 中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构：

![1653986055253][]

*  previous\_entry\_length：前一节点的长度，占1个或5个字节。
    
     *  如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
     *  如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
 *  encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节
 *  contents：负责保存节点的数据，可以是字符串或整数

ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：数值0x1234，采用小端字节序后实际存储值为：0x3412

#### Encoding编码 ####

ZipListEntry中的encoding编码分为字符串和整数两种：  
字符串：如果encoding是以“00”、“01”或者“10”开头，则证明content是字符串

<table> 
 <thead> 
  <tr> 
   <th><strong>编码</strong></th> 
   <th><strong>编码长度</strong></th> 
   <th><strong>字符串大小</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>|00pppppp|</td> 
   <td>1 bytes</td> 
   <td>&lt;= 63 bytes</td> 
  </tr> 
  <tr> 
   <td>|01pppppp|qqqqqqqq|</td> 
   <td>2 bytes</td> 
   <td>&lt;= 16383 bytes</td> 
  </tr> 
  <tr> 
   <td>|10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt|</td> 
   <td>5 bytes</td> 
   <td>&lt;= 4294967295 bytes</td> 
  </tr> 
 </tbody> 
</table>

例如，我们要保存字符串：“ab”和 “bc”

![1653986172002][]

ZipListEntry中的encoding编码分为字符串和整数两种：

*  整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节

<table> 
 <thead> 
  <tr> 
   <th><strong>编码</strong></th> 
   <th><strong>编码长度</strong></th> 
   <th><strong>整数类型</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>11000000</td> 
   <td>1</td> 
   <td>int16_t（2 bytes）</td> 
  </tr> 
  <tr> 
   <td>11010000</td> 
   <td>1</td> 
   <td>int32_t（4 bytes）</td> 
  </tr> 
  <tr> 
   <td>11100000</td> 
   <td>1</td> 
   <td>int64_t（8 bytes）</td> 
  </tr> 
  <tr> 
   <td>11110000</td> 
   <td>1</td> 
   <td>24位有符整数(3 bytes)</td> 
  </tr> 
  <tr> 
   <td>11111110</td> 
   <td>1</td> 
   <td>8位有符整数(1 bytes)</td> 
  </tr> 
  <tr> 
   <td>1111xxxx</td> 
   <td>1</td> 
   <td>直接在xxxx位置保存数值，范围从0001~1101，减1后结果为实际值</td> 
  </tr> 
 </tbody> 
</table>

![1653986282879][]

![1653986217182][]

### 5 Redis数据结构-ZipList的连锁更新问题 ###

ZipList的每个Entry都包含previous\_entry\_length来记录上一个节点的大小，长度是1个或5个字节：  
如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值  
如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据  
现在，假设我们有N个连续的、长度为250~253字节之间的entry，因此entry的previous\_entry\_length属性用1个字节即可表示，如图所示：

![1653986328124][]

ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。

**小总结：**

**ZipList特性：**

*  压缩列表的可以看做一种连续内存空间的"双向链表"
 *  列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
 *  如果列表数据过多，导致链表过长，可能影响查询性能
 *  增或删较大数据时有可能发生连续更新问题

### 6 Redis数据结构-QuickList ###

问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？

答：为了缓解这个问题，我们必须限制ZipList的长度和entry大小。

问题2：但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？

答：我们可以创建多个ZipList来分片存储数据。

问题3：数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？

答：Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

![1653986474927][]

为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：`list-max-ziplist-size`来限制。  
如果值为正，则代表ZipList的允许的entry个数的最大值  
如果值为负，则代表ZipList的最大内存大小，分5种情况：

*  \-1：每个ZipList的内存占用不能超过4kb
 *  \-2：每个ZipList的内存占用不能超过8kb
 *  \-3：每个ZipList的内存占用不能超过16kb
 *  \-4：每个ZipList的内存占用不能超过32kb
 *  \-5：每个ZipList的内存占用不能超过64kb

其默认值为 -2：

![1653986642777][]

以下是QuickList的和QuickListNode的结构源码：

![1653986667228][]

我们接下来用一段流程图来描述当前的这个结构

![1653986718554][]

总结：

QuickList的特点：

*  是一个节点为ZipList的双端链表
 *  节点采用ZipList，解决了传统链表的内存占用问题
 *  控制了ZipList大小，解决连续内存空间申请效率问题
 *  中间节点可以压缩，进一步节省了内存

### 7 Redis数据结构-SkipList ###

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：  
元素按照升序排列存储  
节点可能包含多个指针，指针跨度不同。

![1653986771309][]

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：  
元素按照升序排列存储  
节点可能包含多个指针，指针跨度不同。

![1653986813240][]

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：  
元素按照升序排列存储  
节点可能包含多个指针，指针跨度不同。

![1653986877620][]

小总结：

SkipList的特点：

*  跳跃表是一个双向链表，每个节点都包含score和ele值
 *  节点按照score值排序，score值一样则按照ele字典排序
 *  每个节点都可以包含多层指针，层数是1到32之间的随机数
 *  不同层指针到下一个节点的跨度不同，层级越高，跨度越大
 *  增删改查效率与红黑树基本一致，实现却更简单

### 8 Redis数据结构-RedisObject ###

Redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

1、什么是redisObject：

从Redis的使用者的角度来看，⼀个Redis节点包含多个database（非cluster模式下默认是16个，cluster模式下只能是1个），而一个database维护了从key space到object space的映射关系。这个映射关系的key是string类型，⽽value可以是多种数据类型，比如：  
string, list, hash、set、sorted set等。我们可以看到，key的类型固定是string，而value可能的类型是多个。  
⽽从Redis内部实现的⾓度来看，database内的这个映射关系是用⼀个dict来维护的。dict的key固定用⼀种数据结构来表达就够了，这就是动态字符串sds。而value则比较复杂，为了在同⼀个dict内能够存储不同类型的value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是robj，全名是redisObject。

![1653986956618][]

Redis的编码方式

Redis中会根据存储的数据类型不同，选择不同的编码方式，共包含11种不同类型：

<table> 
 <thead> 
  <tr> 
   <th><strong>编号</strong></th> 
   <th><strong>编码方式</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0</td> 
   <td>OBJ_ENCODING_RAW</td> 
   <td>raw编码动态字符串</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>OBJ_ENCODING_INT</td> 
   <td>long类型的整数的字符串</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>OBJ_ENCODING_HT</td> 
   <td>hash表（字典dict）</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>OBJ_ENCODING_ZIPMAP</td> 
   <td>已废弃</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>OBJ_ENCODING_LINKEDLIST</td> 
   <td>双端链表</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>OBJ_ENCODING_ZIPLIST</td> 
   <td>压缩列表</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>OBJ_ENCODING_INTSET</td> 
   <td>整数集合</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>OBJ_ENCODING_SKIPLIST</td> 
   <td>跳表</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>OBJ_ENCODING_EMBSTR</td> 
   <td>embstr的动态字符串</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td>OBJ_ENCODING_QUICKLIST</td> 
   <td>快速列表</td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>OBJ_ENCODING_STREAM</td> 
   <td>Stream流</td> 
  </tr> 
 </tbody> 
</table>

五种数据结构

Redis中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

<table> 
 <thead> 
  <tr> 
   <th><strong>数据类型</strong></th> 
   <th><strong>编码方式</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>OBJ_STRING</td> 
   <td>int、embstr、raw</td> 
  </tr> 
  <tr> 
   <td>OBJ_LIST</td> 
   <td>LinkedList和ZipList(3.2以前)、QuickList（3.2以后）</td> 
  </tr> 
  <tr> 
   <td>OBJ_SET</td> 
   <td>intset、HT</td> 
  </tr> 
  <tr> 
   <td>OBJ_ZSET</td> 
   <td>ZipList、HT、SkipList</td> 
  </tr> 
  <tr> 
   <td>OBJ_HASH</td> 
   <td>ZipList、HT</td> 
  </tr> 
 </tbody> 
</table>

[1653984583289]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/22c061567a1f4539b9ded9ca5ca26772.png
[1653984624671]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/69d3d11c2e0c4b4a983f7857c9793ab6.png
[1653984648404]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f87cde17df5a4c0dae23400b2ab34a39.png
[1653984787383]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/3abb516545c845de889a09b5738f4de6.png
[1653984822363]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c9ffb4f919f94db9b94f2f802333e290.png
[1653984838306]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/10d9a913701b406fa29539b5f3bbe3fc.png
[1653984923322]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/af793e7466b54b48a237b572aee972f1.png
[1653984942385]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/85c2e6bb4fd045c4865ca8d2a68902e9.png
[1653985149557]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/5dab5c0fef9a4d23b54f67947baed6ea.png
[1653985197214]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/bd35319055fa45c5b69d07869219bffa.png
[1653985276621]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c2d82bd3af944d8ba41914d4e0439fb8.png
[1653985304075]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d55f8bdeabf3444da1a10bb579c92fd1.png
[1653985327653]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c2ba940940ed4a32afff798be9e0e50b.png
[1653985396560]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/dec0a6b73c8c4ca698d784fbd7b4e7d5.png
[1653985497735]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/b834ff2266b54a6d93cd762772babe07.png
[1653985570612]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/77bf8d1899e54a328ef566e29b6b4a26.png
[1653985586543]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0b73aa5d176d4256824813cfd1f5581f.png
[1653985640422]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a970d3ce6f924bc581671ef9902c9c43.png
[1653985716275]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/7a8a6fe5abed448691b1970ecebb2802.png
[1653985743412]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/4e12018858284642a7e4726c834514ca.png
[1653985824540]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/fe6e95206cbd4d1f821dc9a527b675b6.png
[1653985987327]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/6d66157db6d64d58b6e41967509c9012.png
[1653986020491]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/6e95964b1a744db0bc5bbf19e5961066.png
[1653986055253]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f63ac26910cd481f9f8faac7e1eb3931.png
[1653986172002]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/25ef761347664ccb999ccf4ce49ae019.png
[1653986282879]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/16232876684b4d04b856ad299450ef91.png
[1653986217182]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/cb916e962b174e508eafbd4516f9c17f.png
[1653986328124]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a5e64a0e074a42b5b8660fd9c7a54147.png
[1653986474927]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/019aafb8d2d54b0694e84355ab0846ae.png
[1653986642777]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/7876565bf0d94cb889ac18765f369ad8.png
[1653986667228]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c2cc5338fdf14ac98972cdea9045c944.png
[1653986718554]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/b55519a51ff34964a00f6bdf09b9e8f7.png
[1653986771309]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f741816fc6c34df7828145c34ac5c20c.png
[1653986813240]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/e1358b50e5394f22addd259000fe5e2a.png
[1653986877620]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/1eba1fff580b47a38f5ab6367f71445e.png
[1653986956618]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/46d16247f6554709a962617a93530d6e.png