深入学习 Redis Sentinel - 基于 DockerCompose 编排哨兵分布式架构，理解工作原理

小鱼儿 2024-03-08 09:06 53阅读 0赞

**目录**

一、哨兵模式

1.1、为何引入哨兵模式

1.2、Redis Sentinel 分布式架构

1.2.1、概述

1.2.2、工作原理（redis 哨兵的核心功能）

1. 监控：

2. 自动故障转移：

3. 通知

1.2.3、问题：哨兵结点只有一个可以么？

1.3、使用 Docker 和 DockerCompose 模拟部署哨兵模式

1.3.1、前言

1.3.2、准备工作

a）首先要安装好 docker 和 docker-compose.

b）停止之前的 redis 服务器

c）使用 docker 获取 redis 镜像

1.2.3、基于 docker 搭建 redis 哨兵环境

a）分配文件目录结构

b）编写 yml 配置文件

c）编写哨兵结点的三个 conf 配置文件

d）使用 docker-compose 启动 数据结点

e）验证

f）使用 docker-compose 启动 redis-sentinel 结点

日志里为什么全都是报错信息呢？都是什么意思？（重！）

解决方案：

1.2.4、展现哨兵机制

1.2.5、哨兵重新选取主节点的流程

1.2.6、缺陷

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

## 一、哨兵模式 ##

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

### 前言 ###

**重点：为什么引入哨兵模式？什么是哨兵模式？哨兵模式的工作原理？哨兵模式的缺陷？**

### 1.1、为何引入哨兵模式 ###

实际的开发中，对于服务器后端开发，监控程序，是非常重要的！服务器一般要有比较高的可用性，7 \* 24 小时运行，服务器长期运行，总会有一些 “意外” ，具体啥时候出现意外，也不能全靠人工来盯着服务器，所以在早期的主从结构中，会写一个程序来盯着服务器的运行状态.

这个程序需要干两件事：

1.  监控程序：用来发现服务器运行时出现的异常状态.
2.  搭配 “报警程序” ：通过 短信/电话/邮件/微信/钉钉... 等形式给程序员报警，告诉程序员说，这个服务器程序出问题了！

> Ps：互联网公司的程序员，尤其是大厂，公司都会明确要求，程序员手机要 24 小时开机，并且随时关注，报警不仅仅是给这一个程序员，还会给程序员的领导，还有领导的领导~ 关键时候错过领导的电话，可能就会有比较负面的评价，升职加薪就要往后了~

**程序员如何恢复的？**

1.  先看看主节点还能不能抢救，好不好抢救.
2.  如果主节点这边出事的原因很难解决，就需要挑一个从节点，设置为新的主节点
    
    1.  具体的，把选中的从节点，通过 slaveof no one，自立山头.
    2.  其他的从节点，通过修改 slaveof，将 ip 和 port 改为新上任的主节点.
    3.  告知客户端（修改客户端配置），让客户端能够连接新的主节点，用来完成修改数据的操作.
    4.  最后，如果之前挂了的主节点修好了，就可以将其作为一个新的从节点，加入到这个机器当中.

> Ps：
> 
> 1.只要是涉及到人工干预，不说繁琐，至少是很烦人的~
> 
> 2.另外，这个操作过程一旦出错了，就可能让问题更加严重。
> 
> 3.通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也至少需要半个小时以上的恢复时间，也就是说，这半个小时里，整个 redis 就一直不能写？显然不合适。

为了提高 “可用性” 引入以下架构模式~

### 1.2、Redis Sentinel 分布式架构 ###

#### 1.2.1、概述 ####

Redis Sentinel 是⼀个分布式架构，其中包含若干个 Sentinel 节点（哨兵）和 Redis 数据节点，这两种结点之间的哨兵机制，是通过独立的进程来体现的，和 redis-server 是不同进程！redis-sentinel 不负责存储数据，只是对其他的 redis-server 进程起到监控的效果.

#### 1.2.2、工作原理（redis 哨兵的核心功能） ####

![436733d37fee4146b78dc57b8453673e.png][]

##### **1. 监控：** #####

a）redis sentinel 进程，会监控现有的主从结点（这里的监控就是指，sentinel 进程会和 主从结构进程 之间建立 tcp 长连接，通过这样的长连接，定期发送心跳包，看主节点是否挂了，如果 心跳包 没有如果如约而至，就说明 redis 主节点挂了）.

b）如果是从节点挂了，其实没关系，如果是主节点挂了，哨兵就要发挥作用了，此时一个哨兵发现了主节点挂了，还不够，需要多个哨兵来认同这件事，主要防止出现误判（网络抖动，导致心跳包丢失）.

c）如果主节点确实挂了，这些哨兵结点中，就会选举出一个 leader，由这个 leader 负责从现有的从节点中，挑选出一个新的 主节点.

##### **2. 自动故障转移：** #####

d） 挑选出新的主节点之后，哨兵结点就会自动控制被选中的结点，执行 slaveof no one，让他先自立山头，然后再控制其他从节点，修改 slaveof 到新的主节点上.

##### **3. 通知** #####

e）哨兵结点会自动通知客户端程序，告知新的主节点是谁，后续，客户端再进行写操作，就会针对新的主节点进行操作了.

> Ps：以上这三大点，也是 redis 哨兵的核心功能.**（这里只是粗略的讲了以下 “哨兵重新选取主节点的流程” ，后面会详细讲！这是面试经常会问的问题！）**

#### 1.2.3、问题：哨兵结点只有一个可以么？ ####

redis 哨兵结点，只有一个也是可以的.

但值得注意的是，再分布式系统中，应该避免 “单点” 问题（1.一个服务器挂了，整个就服务就瘫痪了；2.并发量有限）.

在 redis 中可能会导致以下问题：

1.  一个哨兵结点，自身也是容易出现问题的，万一这一个哨兵结点挂了，后续 redis 结点挂了，就无法进行自动恢复了.
2.  出现误判的概率也比较高，因为网络传输数据是容易出现抖动、延迟、丢包等问题的.

> Ps：哨兵结点，最好搞奇数个，最少也要有 3 个

### 1.3、使用 Docker 和 DockerCompose 模拟部署哨兵模式 ###

#### 1.3.1、前言 ####

这里我们将以下图为例，通过 Docker 和 DockerCompose 部署和编排 3 个哨兵和 1 个主 2 个从结点.

![436733d37fee4146b78dc57b8453673e.png][]

案例说，这 6 个结点是要部署到 6 个不同的服务器主机上的.

但我这里只有一个云服务器（实际的工作中，上述结点放在一个云服务器上事没有意义的，这么做也是没办法，经济有限）， 如果直接部署，就需要小心避开这些冲突：端口号、配置文件、数据文件....

> 使用 docker 就可以有效解决上述问题~

虚拟机，就是在电脑上通过软件模拟出另外一些硬件（构造了一个台虚拟电脑），也就是说，通过虚拟机这样的软件，就可以使用一个计算机，来模拟出多个电脑的情况.

**但是虚拟机有个很大的问题：很吃配置，这个事情对于我的云服务器来说，压力山大~**

docker 可以认为是一个 “轻量级” 的虚拟机（现在后端开发很流行这个组件），既不吃很多的硬件资源，又可以起到虚拟机这样的隔离环境的效果（即使你云服务器配置很低，也能构造出好几个这样的虚拟环境）.

#### 1.3.2、准备工作 ####

##### **a）首先要安装好 docker 和 docker-compose.** #####

这里我之前有出过专门的文章，可以去翻翻.

##### **b）停止之前的 redis 服务器** #####

1.  如果是通过 redis-server 启动服务器，就必须搭配 kill 命令来停止.
2.  如果是通过 service redis-server start 启动服务器，必须搭配 service redis-server stop 来停止.
3.  如果使用 kill 命令停止 service redis-server start ，这个 redis-server 进程会自动启动.

##### **c）使用 docker 获取 redis 镜像** #####

通过以下命令，就可以从 docker hb 上拉取 redis 5.0.9 的镜像

docker pull redis:5.0.9

![845bcabcfd8544a9ace72a52a3e03914.png][]

#### 1.2.3、基于 docker 搭建 redis 哨兵环境 ####

> Ps：此处涉及到多个 redis server 和多个 redis 哨兵结点，每一个 redis server 和每一个 redis 哨兵结点都是作为一个单独的容器（按照案例，这里总共要部署 6 个容器），**为了方便部署，使用 docker-compose 进行容器编排**.

##### **a）分配文件目录结构** #####

![9fbe0a1965e9455bab84dc1f46f01cdf.png][]

由于 redis 哨兵结点是单独的 redis 服务器进程，因此之后对于哨兵和主从结点的 yml 配置文件要分开！！！

虽然也可以使用一个 yml 文件 直接启动 6 个容器，但是如果 6 个容器同时启动，**可能是 哨兵 先启动完成，数据节点后启动完成，哨兵可能就会先认为是数据结点挂了！**虽然从大体上来看不影响，但是会影响到我们对执行日志的观察.

##### b）编写 yml 配置文件 #####

这里分别在 redis-data 目录 和 redis-sentinel 目录下创建一个 yml 配置文件（注意，文件名必须是 docker-compose.yml）

![1da0ad0698c14bfab6279abd7d31fac7.png][]

分别用来描述 3 个数据结点和 3 个哨兵结点 ， 具体要创建哪些容器，每个容器运行的各种参数，描述清除。

后续通过一个简单的命令，就可以批量进行 启动/停止 这些容器了.

> Ps：下来讲到的配置文件不需要记，只需要了解其中一些参数的意思即可，实际工作中不可能让你去写，只会让你去 copy 现有的，对关键参数进行修改.

数据结点配置文件如下：

version: '3.7'
    services:
      master:
        image: 'redis:5.0.9'
        container_name: redis-master
        restart: always
        command: redis-server --appendonly yes
        ports:
          - 6379:6379
      slave1:
        image: 'redis:5.0.9'
        container_name: redis-slave1
        restart: always
        command: redis-server --appendonly yes --slaveof redis-master 6379
        ports:
          - 6380:6379
      slave2:
        image: 'redis:5.0.9'
        container_name: redis-slave2
        restart: always
        command: redis-server --appendonly yes --slaveof redis-master 6379
        ports:
          - 6381:6379

对一些关键参数的解释：

*  image：当前容器是基于哪个镜像创建的（镜像就相当于模板，启动镜像就可以构建出容器）.
 *  container\_name：自定义容器的名字。docker 中可以通过容器名字, 作为 ip 地址, 进⾏相互之间的访问.
 *  restart：容器遇到一些异常情况终止了，是否重启（always 表示一旦遇到异常情况，立刻重启 ）.
 *  command：用什么命令来启动服务.
 *  ports：这里的规则是 \[宿主机端口\] \[容器内部端口\]。上述配置文件中，要启动三个容器（master、slave1、slave2），这三个容器的内部端口号都是自成一个小天地，也就是说，容器 1 的 6379 和 容器 2 的 6379 之间是不会有冲突的（两个容器可以视为两个主机）；有的时候，希望容器外访问容器内部的端口，需要进行端口映射，把容器内吨端口映射到宿主机上，后续访问宿主机这个端口，就相当于在访问对应容器的对应端口了.

> Ps：站在宿主的角度，访问上述几个端口的时候，也不知道这个端口是一个宿主机上的服务，还是来自于容器内部的服务，只要正常使用即可。这里的映射过程很像 NAT.

![bb91e206f3f14e258ffe296e5cba8b40.png][]

哨兵结点配置文件如下：

version: '3.7'
    services:
      sentinel1:
        image: 'redis:5.0.9'
        container_name: redis-sentinel-1
        restart: always
        command: redis-sentinel /etc/redis/sentinel.conf
        volumes:
          - ./sentinel1.conf:/etc/redis/sentinel.conf
        ports:
          - 26379:26379
      sentinel2:
        image: 'redis:5.0.9'
        container_name: redis-sentinel-2
        restart: always
        command: redis-sentinel /etc/redis/sentinel.conf
        volumes:
          - ./sentinel2.conf:/etc/redis/sentinel.conf
        ports:
          - 26380:26379
      sentinel3:
        image: 'redis:5.0.9'
        container_name: redis-sentinel-3
        restart: always
        command: redis-sentinel /etc/redis/sentinel.conf
        volumes:
          - ./sentinel3.conf:/etc/redis/sentinel.conf
        ports:
          - 26381:26379

对一些关键参数的解释：

volumes：建立映射. 哨兵结点在运行的过程中，会对配置文件进行自动修改，因此就不能只拿 /etc/redis/sentinel.conf 这一个配置文件，给三个容器分别进行映射. 以上 volumes 的内容，就需要我们在当前目录下（redis-sentinel目录下）继续创建三个 conf 文件.

##### c）编写哨兵结点的三个 conf 配置文件 #####

创建 sentinel1.conf、sentinel2.conf、sentinel2.conf 这三个配置文件，内容可以是一样的，容器启动后，会自动对这三个 conf 文件进行修改.

![257faa10df494738809a600a51e7792b.png][]

bind 0.0.0.0
    port 26379
    sentinel monitor redis-master redis-master 6379 2
    sentinel down-after-milliseconds redis-master 1000

参数解释：

*  bind 0.0.0.0：表示让其他结点进行访问.
 *  port：容器内部使用的端口.
 *  sentinel monitor redis-master 6379 2：**这里是告诉哨兵结点，需要监控哪个 redis 服务器**. redis-master 这里其实是 ip 地址，是使用 docker 自动进行域名解析. 最后的 2 表示法定票数，这里的票数就是为了更稳健的确认，当前 redis-server 是否挂了，不能只听一个哨兵的一面之词.
 *  sentinel down-after-milliseconds redis-master 1000：这里表示心跳包的超时时间.（此处是 1000ms）.

##### d）使用 docker-compose 启动 数据结点 #####

使用 docker-compose up -d 命令（-d 表示后天运行）启动所有容器（必须和 docker-compose.yml 同文件路径下）

> Ps：如果启动后发现前面配置有误，需要重新操作，使用 docker-compose down 即可停止刚创建好的容器.

如果出现以下错误，说明 yml 中配置的 version 不支持，修改成报错信息中支持的版本即可（以下报错中提示，只支持 version 为 2.2 或者 3.3 的版本）

![0110e05645f94e8d8c4e8f508bf520d0.png][]

如下信息为启动成功

![76c7c67cd4f44ff7901647b4d7bbf7c4.png][]

通过 redis-compose logs 命令查看运行日志信息

![ef4a3146221f47dcbb9f5a66941ef12d.png][]

##### e）验证 #####

通过连接 redis 验证主从结构

连接主节点：redis-cli -p 6379

![5368ba5955954be48f23dfec5f59c99f.png][]

连接第一个从节点：redis-cli -p 6380

![324e987672a140e696473c45fb82b4cd.png][]

连接第二个从节点：redis-cli -p 6381

![5c7dbf273bca4f1ea299ec776183200e.png][]

##### f）使用 docker-compose 启动 redis-sentinel 结点 #####

在 redis-sentine 目录下，使用 docker-compose up -d 启动所有容器

![ab067e5267e2456fb15aa9ed62c40a2c.png][]

通过 docker-compose logs 查看日志文件

![62379ef475d6426780a812d998fdb8f5.png][]

> ##### 日志里为什么全都是报错信息呢？都是什么意思？（重！） #####

docker-compose 一下启动了 N 个容器，此时 N 个容器都是处于同一个 “局域网” 中，可以使这 N个容器之间可以互相访问~

但是！！！ 三个 redis-server 结点是一个局域网，三个哨兵结点是另外一个局域网，默认情况下，这两网络是不互通的！！！

##### 解决方案： #####

可以使用 docker-compose 把此处两组服务放到同一个局域网中.

具体的，使用 docker network ls 列出当前 docker 中的局域网，就可以拿到 redis-data 服务的 docker-compose 文件所在目录名（用来修改配置文件）

![2325c9a12cc04beea361c615648c94b8.png][]

修改哨兵结点中配置文件，在之前配置文件的基础上加上如下配置：

networks:
      default:
        external:
          name: redisdata_default

然后再启动哨兵，观察日志如下：

![4e6abaa1306344d5acf49171d6731bb5.png][]

打开 sentinel1.conf 文件，就可以看到 ，哨兵结点启动之后，自动进行修改的内容如下：

![283e4d0c529b4cf4b12328e3c22f1217.png][]

#### 1.2.4、展现哨兵机制 ####

哨兵存在的意义，就是在 redis 主从机构出现问题的时候（主节点挂了），此时哨兵结点能够自动帮我我们重新选出一个主节点，来代替之前挂了的结点，保证整个 redis 仍然是可用的状态.

这里我们可以通过 docker stop redis-master 命令手动把主节点干掉，然后观察哨兵日志，可以看到

![c66517bec9e3432d870ab24387dff5f8.png][]

1.  sdown 主观下线：本哨兵结点，认为该主节点挂了.
2.  odown 客观下线：好几个哨兵都认为该主节点挂了，也就是达到了法定票数，此时这个主节点挂了的事情就被实锤了.

此时就需要先选出一个 leader哨兵，由这个 leader 哨兵结点选出一个从节点，作为新的主节点.

接着往下看日志，就可以看出 3 个哨兵的投票过程.

![da987ace969d4e65bda3864016d2340e.png][]

#### 1.2.5、哨兵重新选取主节点的流程 ####

**1. 主观下线（sdown）：**哨兵节点通过心跳包，判定 redis 服务器是否正常工作. 如果心跳包没有如约而至，就说明 redis 服务器挂了.

> Ps：此时还不能排除网络波动的影响，因此就只能单方面的认为这个 redis 结点挂了.
> 
> **比如是否可能出现非常严重的网络波动，导致所有哨兵都联系不上 redis 主节点，误判成挂了呢？**
> 
> 当然可能是有的！如果出现这个情况，怕是用户的客户端也连接不上 redis 主节点，此时这个主节点基本上也就无法正常工作了.
> 
> “挂了” 不一定是进程崩了，只要无法正常访问，都可以视为挂了.

**2. 客观下线（odown）：**多个哨兵都认为主节点挂了，（认为挂了的哨兵数目到达 “法定票数”），哨兵们就认为这个主节点是 客观下线.

**3. 多个哨兵结点会通过投票的方式，选出一个 leader 哨兵结点，有这个 leader 负责选出一个 从节点 作为新的主节点.**

具体的，每个哨兵手里只有一票（接下来的投票过程，就是看谁反应快，网络延迟小）

1 号哨兵 第一个发现当前是客观下线之后，就立即给自己投了一票（推举自己成为 leader），并且告诉 2 3 ，我来负责这个事情（2 3 当他们没有投出这一票的时候，拉票请求，就会投出去，如果有多个拉票请求，就投给最先到达的） ，如下：

![93f0c437765d41dbba84e52c0bdd3339.png][]

2 号哨兵不乐意，认为自己和 1 号同时发现，也给自己投了一票，3 号哨兵慢了半拍，才发现是客观下线，就把这一票投给了 1 号哨兵，如下：

![659d5ed689b443aab1dc27768d9a8945.png][]

如果总的票数到达了哨兵总数的一半，选举就完成了.（把哨兵个数设置成奇数个结点，就是为了方便投票）.

**4. 此时 leader 选举完毕，leader 需要挑选出一个从节点，作为新的主节点.**

具体的挑选从节点的规则如下：

a）优先级：每个 redis 数据结点，都会在配置文件中有一个优先级的设置（slave-priority）优先级高的从节点，就会胜出（如果没有设置，默认优先级都是一样的）. 如果当前优先级一样，就看下一个规则.

b）offset ：offset 就是从节点从主节点这边同步数据的进度，数值越大，说明从结点的数据和主节点的数据越接近，因此，最大的胜出. 如果当前优先级一样，就看下一个规则.

c）run id：每个 redis 结点启动的时候随机生成一串数字（大小全随机），这时候就是相当于是随机了.

*这就像是，大学的学生如果和辅导员有亲戚关系，那么班长就是钦定的，如果没有关系，那么就看谁更听她的话，如果都是刺头，那就只能看谁名字好听了~*

**5. 新的主节点指定好了之后，leader 就会控制这个结点，执行 slave no one，让其独立山头，成为 master，然后再控制其他节点，执行 slave of，让其他节点以新的 master 作为主节点.**

**6. 最后，如果之前挂掉的主节点修复了，就直接让这个节点变为从节点加入到机器中**（为什么不在成为主节点？因为成为主节点，还需要通过 slave of 修改正在运行的主节点，这个过程，可能会丢失数据）.

使用 docker start redis-master 命令启动恢复之前挂掉的主节点后，会发现，已经变为从节点

![497dd04dc1064efcb034f6168c09d24a.png][]

#### 1.2.6、缺陷 ####

哨兵 + 主从解决的问题是 “提高可用性”，不能解决极端情况下写丢失的问题~

最关键的一点就是，在数量十分庞大的情况下，这种模式就难以胜任了！

因此，redis 集群，就是解决存储容量问题的有效方案.

![7354be56432e42f0884f3918f373c6e7.gif][]

[436733d37fee4146b78dc57b8453673e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/5efd441529884264bb110297d65b3f75.png
[845bcabcfd8544a9ace72a52a3e03914.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/c20dae58b90a409bb9ec32ce67f3b849.png
[9fbe0a1965e9455bab84dc1f46f01cdf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/42901ce08df54a00bdcd2376c942e995.png
[1da0ad0698c14bfab6279abd7d31fac7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/65e948ce26fe485db3b3a4e84774ad67.png
[bb91e206f3f14e258ffe296e5cba8b40.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/f7f3acfd19974a868c6bb02bbb4a00db.png
[257faa10df494738809a600a51e7792b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/dfee872e314a4ccd99847a303bb6d205.png
[0110e05645f94e8d8c4e8f508bf520d0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/6396405378ca47e3958bfcb396cdeceb.png
[76c7c67cd4f44ff7901647b4d7bbf7c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/86eed5032d894f7aa2676bd21ba5edfc.png
[ef4a3146221f47dcbb9f5a66941ef12d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/3d3eb428d4e74a81bb28f29db91defa8.png
[5368ba5955954be48f23dfec5f59c99f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/938b8d02331b4f8e9b8971204d3d6ca9.png
[324e987672a140e696473c45fb82b4cd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/d1e5bdef92134583a4f5b4e2680bebad.png
[5c7dbf273bca4f1ea299ec776183200e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/e80ce031dd2649d0bcb487984e30e4d7.png
[ab067e5267e2456fb15aa9ed62c40a2c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/6f2a8ee6dec243e58312ce26075af731.png
[62379ef475d6426780a812d998fdb8f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/50655560aecf44f3826a806d29b7c54f.png
[2325c9a12cc04beea361c615648c94b8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/c723e456f8d844a2bbf6cfad36a71fd0.png
[4e6abaa1306344d5acf49171d6731bb5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/4d88a1dc44e846e5a0564c208645043e.png
[283e4d0c529b4cf4b12328e3c22f1217.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/2c3c2293a28b4c8187b1d7fe121cb3fb.png
[c66517bec9e3432d870ab24387dff5f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/478cd3b039f242ad96ced8c6d94e0dba.png
[da987ace969d4e65bda3864016d2340e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/65771f33a4064ffba590de30d22a5713.png
[93f0c437765d41dbba84e52c0bdd3339.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/6b500f2815bb4e55bf59e2506efa549d.png
[659d5ed689b443aab1dc27768d9a8945.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/2513ebae531b4397a0dfa39b4f981806.png
[497dd04dc1064efcb034f6168c09d24a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/5a611b25e8574bad80dcb5a0ba955a0a.png
[7354be56432e42f0884f3918f373c6e7.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/4ece8417fc894860a1b4e2336f2bf64f.png