interview1-DB篇

心已赠人 2024-03-24 20:23 36阅读 0赞

![5e0b3384a5bd4a6fbc0f01c88cbce149.png][]

需要项目经验可自行上Gitee寻找项目资源

![84917cdb7ef54146add5b696847c9b5e.png][]

## ![5efe223d3b8242a0af72d6a57e73a523.png][] 一、Redis篇 ##

![c57e6bc219e04f64afaadec29d966860.png][]

### 1、缓存 ###

缓存的要点可分为穿透、击穿、雪崩，双写一致、持久化，数据过期、淘汰策略。

#### （1）穿透、击穿、雪崩 ####

##### 1.缓存穿透 #####

![61c527e3a35c4fdb8b02b0f4812a286f.png][]

查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库。

*  解决方法一：缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存。

优点：简单。 缺点：消耗内存，可能会发生不一致的问题

*  解决方案二：布隆过滤器。

布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。

数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

##### 2.缓存击穿 #####

![0ee2b6e4c8624ffca228bd7956c595a3.png][]

给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮

*  解决方法一：互斥锁

当缓存失效时，不立即去load db，先使用如 Redis 的setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法

*  解决方法二：逻辑过期

①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间

②：当查询的时候，从redis取出数据后判断时间是否过期

③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新

如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题

如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。

##### 3.雪崩问题 #####

![3a228a48c0ba41d2afaf07dfda5c2abb.png][]

指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案一般主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

#### （2）双写一致、持久化 ####

##### 1.双写一致 #####

记得要先介绍业务场景，数据是一致性要求高，还是允许延迟。

![f1e75df9b46f4facaf45fce27165ed31.png][]

也就是redis缓存和db写入数据同步的问题，当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致。

*  解决方法一：读写锁。

采用的是redisson实现的读写锁，在读的时候添加共享锁，可以保证读读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写，读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

*  解决方法二：延迟双删。

如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。

*  解决方法三：使用canal。

![37668b24464e4a2098e058aec7e0f9e0.png][]

##### 2.持久化 #####

在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据。

![4044ce5c5b1644eea7bd2c26e39aefdc.png][]

这两种方式，哪种恢复的比较快呢？

RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令。

#### （3）数据过期、淘汰策略 ####

##### 1.数据过期 #####

Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就被称之为数据的删除策略（数据过期策略）。

*  惰性删除：设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key

![840e0ac3ce734c73a34534968579ef68.png][]

*  定期删除：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。

SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的 **hz** 选项来调整这个次数

FAST模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于2ms，每次耗时不超过1ms

![1d9ecc0f19794257ba4eb821a7e129f0.png][]

Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用。

##### 2.淘汰策略 #####

当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

*  LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
 *  LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

![63bd6b76820746f5b77d2365804adf04.png][]

1.  优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
2.  如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
3.  如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
4.  如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

### 2、分布式锁 ###

*  Redis分布式锁如何实现？

在redis中提供了一个命令setnx(SET if not exists) 由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的。

*  那你如何控制Redis实现分布式锁有效时长呢？

![3e48ad4a748447a69e9b879d46b692f9.png][]

redis的setnx指令不好控制这个问题，我们当时采用的redis的一个框架redisson实现的。在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加锁的持有时间，当业务执行完成之后需要使用释放锁就可以了。

*  redisson实现的分布式锁是可重入的吗？

嗯，是可以重入的。这样做是为了避免死锁的产生。这个重入其实在内部就是判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计数，如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构，大key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，value是当前线程重入的次数。

### 3、集群 ###

#### （1）主从复制 ####

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

![3361ecc1ac774e958b84062416ed92e5.png][]

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。

offset：偏移量，随着记录在repl\_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

![fc271d53febe402cac2a0f918a228441.png][]

主从同步数据的流程：

全量同步是指从节点第一次与主节点建立连接的时候使用全量同步，流程是这样的：

1.  从节点请求主节点同步数据（replication id、 offset ）
2.  主节点判断是否是第一次请求，是第一次就与从节点同步版本信息（replication id和offset）
3.  主节点执行bgsave，生成rdb文件后，发送给从节点去执行
4.  在rdb生成执行期间，主节点会以命令的方式记录到缓冲区（一个日志文件）
5.  把生成之后的命令日志文件发送给从节点进行同步

增量同步指的是，当从节点服务重启之后，数据就不一致了，所以这个时候，从节点会请求主节点同步数据:

1.  从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值
2.  主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

#### （2）哨兵模式 ####

哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

*  监控：Sentinel 会不断检查您的master和slave是否按预期工作。
 *  自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。
 *  通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。

redis集群脑裂，该怎么解决呢？

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失。

解决：我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失。

#### （3）分片集群 ####

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：海量数据存储问题、高并发写的问题。

使用分片集群可以解决上述问题，分片集群特征：

*  集群中有多个master，每个master保存不同数据
 *  每个master都可以有多个slave节点
 *  master之间通过ping监测彼此健康状态
 *  客户端请求可以访问集群任意节点，最终都会被转发到正确节点

Redis 分片集群引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

### ![062647a0c6f147849b88d826c730fbb0.png][]4、Redis为什么这么快 ###

1.  完全基于内存的，C语言编写
2.  采用单线程，避免不必要的上下文切换可竞争条件
3.  使用多路I/O复用模型，非阻塞IO

例如：bgsave 和 bgrewriteaof 都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞

能解释一下I/O多路复用模型？

Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度， I/O多路复用模型主要就是实现了高效的网络请求。

I/O多路复用模型是指利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。

Redis网络模型:

![bf0a112d3ac14057a15a9b772fb632f8.png][]

## 二、MySQL篇 ##

![a14658036e454e5d9c1de8abed5a6319.png][]

### 1、定位慢查询 ###

表象：页面加载过慢、接口压测响应时间过长（超过1s）

1.  方案一：开源工具

*  调试工具：Arthas
 *  运维工具：Prometheus 、Skywalking

1.  方案二：MySQL自带慢日志
    
    慢查询日志记录了所有执行时间超过指定参数（long\_query\_time，单位：秒，默认10秒）的所有SQL语句的日志如果要开启慢查询日志，需要在MySQL的配置文件（/etc/my.cnf）中配置如下信息：

![481b918ca3a84af4a7ae279a82d734cf.png][]

配置完毕之后，通过以下指令重新启动MySQL服务器进行测试，查看慢日志文件中记录的信息 /var/lib/mysql/localhost-slow.log。 ![7266e44b632b4b6ca76ef1e564108188.png][]

### 2、SQL执行计划 ###

那这个SQL语句执行很慢, 如何分析呢？

![dc342fc538ae4b649d17b9e03522770a.png][]

可以采用EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息。

![22cfb4bfb69948da80ab69e0c7198b0d.png][]

可以采用MySQL自带的分析工具 EXPLAIN

1.  通过key和key\_len检查是否命中了索引（索引本身存在是否有失效的情况）
2.  通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描
3.  通过extra建议判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

如果一条sql执行很慢的话，我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况，比如在这里面可以通过key和key\_len检查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效的情况，第二个，可以通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复。

### **3、索引** ###

索引（index）是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构（B+树），这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

*  索引（index）是帮助MySQL高效获取数据的数据结构(有序)
 *  提高数据检索的效率，降低数据库的IO成本（不需要全表扫描）
 *  通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗

#### **（1）存储引擎** ####

存储引擎是存储数据、建立索引、更新/查询数据等技术的实现方式 。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型。

在mysql中提供了很多的存储引擎，比较常见有InnoDB、MyISAM、Memory

*  InnoDB存储引擎是mysql5.5之后是默认的引擎，它支持事务、外键、表级锁和行级锁
 *  MyISAM是早期的引擎，它不支持事务、只有表级锁、也没有外键，用的不多
 *  Memory主要把数据存储在内存，支持表级锁，没有外键和事务，用的也不多

#### **（2）索引底层数据结构** ####

MySQL的InnoDB引擎采用的B+树的数据结构来存储索引

*  阶数更多，路径更短
 *  磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据
 *  B+树便于扫库和区间查询，叶子节点是一个双向链表![e54b715a351e483aa03f0fb06f8679cb.png][]
    
    ![876f66d415f547b49f4ea0f5b5758bc4.png][]

#### **（3）聚簇和非聚簇索引** ####

![d3f48b8ba3a84e3a9cd2afb7d4701167.png][]

*  如果存在主键，主键索引就是聚集索引。
 *  如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
 *  如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。

聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个，一般情况下主键在作为聚簇索引的。

非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自己定义的索引都是非聚簇索引。

回表查询是通过二级索引找到对应的主键值，到聚集索引中查找整行数据，这个过程就是回表。

覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到 。

覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select \*，尽量在返回的列中都包含添加索引的字段。

![7428193861c34ca8a3d96d469d0e8a60.png][]

mysql超大分页处理方法：超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引 和 子查询来解决先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了因为查询id的时候，走的覆盖索引，所以效率可以提升很多。

#### **（4）索引创建原则** ####

一般有以下原则：主键索引、唯一索引、根据业务创建的索引(复合索引)

1.  数据量较大，且查询比较频繁的表（一般超过10万）
2.  常作为查询条件、排序、分组的字段
3.  字段内容区分度高
4.  内容较长，使用前缀索引
5.  尽量联合索引
6.  要控制索引的数量
7.  如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它

#### **（5）索引失效场景** ####

*  违反最左前缀法则
 *  范围查询右边的列，不能使用索引
 *  不要在索引列上进行运算操作， 索引将失效
 *  字符串不加单引号，造成索引失效。(类型转换)
 *  以%开头的Like模糊查询，索引失效

### **4、SQL优化经验** ###

#### **（1）表的设计优化** ####

*  比如设置合适的数值（tinyint int bigint），要根据实际情况选择。
 *  比如设置合适的字符串类型（char和varchar）char定长效率高，varchar可变长度，效率稍低。

#### **（2）SQL语句优化** ####

*  SQL语句优化SELECT语句务必指明字段名称（避免直接使用select \* ）
 *  SQL语句要避免造成索引失效的写法
 *  尽量用union all代替union union会多一次过滤，效率低
 *  避免在where子句中对字段进行表达式操作
 *  Join优化 能用innerjoin 就不用left join right join，如必须使用 一定要以小表为驱动，内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join 或 right join，不会重新调整顺序

#### **（3）主从复制、读写分离** ####

![9e9acb8b351e440791c28e73dfdf9788.png][]

主从复制、读写分离如果数据库的使用场景读的操作比较多的时候，为了避免写的操作所造成的性能影响 可以采用读写分离的架构。读写分离解决的是，数据库的写入，影响了查询的效率。

#### **（4）分库分表**  ####

分库分表的时机：

1.  前提，项目业务数据逐渐增多，或业务发展比较迅速 （单表数据达到1000W或20G）
2.  优化已解决不了性能问题（主从读写分离、查询索引…）
3.  IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）

拆分策略：

![9493e2d696744a60836c85eda7cb71ab.png][]

具体拆分策略

1.  水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题
2.  水平分表，解决单表存储和性能的问题
3.  垂直分库，根据业务进行拆分，高并发下提高磁盘IO和网络连接数（微服务常用）
4.  垂直分表，冷热数据分离，多表互不影响

水平拆分时一般使用mycat中间件进行分库分表：

![0ecaabc40a96402795d1601377e26c8c.png][]

mycat中间件可以解决分库分表时遇到的问题，比如：

*  分布式事务一致性问题
 *  跨节点关联查询
 *  跨节点分页、排序函数
 *  主键重复

### **5、事务** ###

#### **（1）事务特征** ####

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

事务的ACID特性：

*  原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
 *  一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
 *  隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
 *  持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

redo log: 记录的是数据页的物理变化，服务宕机可用来同步数据

undo log ：记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据

redo log保证了事务的持久性，undo log保证了事务的原子性和一致性

#### **（2）隔离级别** ####

并发事务问题: 脏读、不可重复读、幻读

![90b42913e0484ffd98c7ed489ef419a2.png][]

解决方案：对事务进行隔离

隔离级别：读未提交、读已提交、可重复读、串行化

![17ae61d096b743a98dec41b192c1f1e9.png][]

注意：事务隔离级别越高，数据越安全，但是性能越低。

事务的隔离性是靠什么保证的？

*  锁：排他锁（如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁）
 *  mvcc : 多版本并发控制

#### **（3）MVCC** ####

全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突MVCC的具体实现，主要依赖于数据库记录中的隐式字段、undo log日志、readView。

*  隐藏字段：

1.  trx\_id(事务id)，记录每一次操作的事务id，是自增的
2.  roll\_pointer(回滚指针)，指向上一个版本的事务版本记录地址

*  undo log：

1.  回滚日志，存储老版本数据
2.  版本链：多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll\_pointer指针形成一个链表

*  readView解决的是一个事务查询选择版本的问题

1.  根据readView的匹配规则和当前的一些事务id判断该访问那个版本的数据
2.  不同的隔离级别快照读是不一样的，最终的访问的结果不一样

RC ：每一次执行快照读时生成ReadView

RR：仅在事务中第一次执行快照读时生成ReadView，后续复用

### 6、主从同步原理 ###

![d9587d37ec3645dfbb75d602b10c24b6.png][]

MySQL主从复制的核心就是二进制日志。

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

![d7512f9b364e43e1b2306bef5fae7755.png][]

复制分成三步：

1.  Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
2.  从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
3.  slave重做中继日志中的事件，将改变反映它自己的数据。

[5e0b3384a5bd4a6fbc0f01c88cbce149.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/ae01b341a6fe4aaeb9b8737f2e1dc877.png
[84917cdb7ef54146add5b696847c9b5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/d934c498c69a42548a48e120a746f998.png
[5efe223d3b8242a0af72d6a57e73a523.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/33847f27d1654960ba3a37ef94133535.png
[c57e6bc219e04f64afaadec29d966860.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/a3ce4b5b2ec7400d8fb869d3c08c2742.png
[61c527e3a35c4fdb8b02b0f4812a286f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/be094d98f9d3454aaf0ba4c8487a4978.png
[0ee2b6e4c8624ffca228bd7956c595a3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/feedd763fce849d48bea9ae90429c769.png
[3a228a48c0ba41d2afaf07dfda5c2abb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/0861e18092ed4687a37d77b9837bf671.png
[f1e75df9b46f4facaf45fce27165ed31.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/9d3f9775a6e7413ea5ebecb935f386a6.png
[37668b24464e4a2098e058aec7e0f9e0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/12731d3e98c04b1eadd9ff3272ff9d81.png
[4044ce5c5b1644eea7bd2c26e39aefdc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/fab8061a2d3a4cdf868d179e47ce20a0.png
[840e0ac3ce734c73a34534968579ef68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/db5f9519fcc949ef9dd6963e2a4fae65.png
[1d9ecc0f19794257ba4eb821a7e129f0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/9970e7b2df5e433cb48f85a088eddfd5.png
[63bd6b76820746f5b77d2365804adf04.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/f1a541121e7e4d20acb7b3a291e9d0aa.png
[3e48ad4a748447a69e9b879d46b692f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/f2bb262f359d47b4bd0d017122629287.png
[3361ecc1ac774e958b84062416ed92e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/341ae7f4e672449c9a681b0aca83eeb8.png
[fc271d53febe402cac2a0f918a228441.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/23c3a8c49a03464680de4df020c9e6d3.png
[062647a0c6f147849b88d826c730fbb0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/d8720219b0324d2eab25b17cbf661887.png
[bf0a112d3ac14057a15a9b772fb632f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/fed9d1c2c4d04d32a3a7252de15adf7c.png
[a14658036e454e5d9c1de8abed5a6319.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/5a279ec162c84256bd02282bdd961511.png
[481b918ca3a84af4a7ae279a82d734cf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/ece7a195f5254828a813a1a5fa7a4f64.png
[7266e44b632b4b6ca76ef1e564108188.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/064de68edfe74d2b90de227f11fdf7d9.png
[dc342fc538ae4b649d17b9e03522770a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/3c5c40cacd8b476f9734e474b8f8fcc3.png
[22cfb4bfb69948da80ab69e0c7198b0d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/95fbebed8bc14fc188914cb4b31ee951.png
[e54b715a351e483aa03f0fb06f8679cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/0500774cc72f44fcbfc8d512189a5faf.png
[876f66d415f547b49f4ea0f5b5758bc4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/947d4204c0c342ecb9a2c86e221ea82d.png
[d3f48b8ba3a84e3a9cd2afb7d4701167.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/9b0eb0a970e6498caac6ad30b1cd2ef5.png
[7428193861c34ca8a3d96d469d0e8a60.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/12fc50e276bc4772a71d49685db7e4c7.png
[9e9acb8b351e440791c28e73dfdf9788.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/288b61e4b28449e990d7f0b062eeb084.png
[9493e2d696744a60836c85eda7cb71ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/37b2a008366649898d65ea4cb785993d.png
[0ecaabc40a96402795d1601377e26c8c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/7f00edc731614b66aadf3ca97a7a3b6c.png
[90b42913e0484ffd98c7ed489ef419a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/c682b120a5294aa8acf3d1f8709777a7.png
[17ae61d096b743a98dec41b192c1f1e9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/c8722586e68b4b9bb48960ee9cc79617.png
[d9587d37ec3645dfbb75d602b10c24b6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/b6840554f181444baf73969dd59ade97.png
[d7512f9b364e43e1b2306bef5fae7755.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/bff65b69376548cd8e50319acf13ce1c.png