RabbitMQ消息队列相关的面试题汇总

拼搏现实的明天。 2024-01-20 08:13 23阅读 0赞

## RabbitMQ面试题 ##

#### 1. rabbitmq 的使用场景有哪些? ####

>  *  ①. **跨系统的异步通信**: 所有需要异步交互的地方都可以使用消息队列.
>  *  ②. **多个应用之间的解耦**: 由于消息队列是平台无关和语言无关的,而且语义上也不再是函数调用,因此适合作为多个应用之间的松耦合的接口.
>  *  ③. **应用内的同步变异步**: 比如订单处理,就可以由前端应用将订单信息放到队列,后端应用从队列里依次获得消息处理,高峰时的大量订单可以积压在队列里慢慢处理掉.
>  *  ④. **消息驱动的架构(EDA)**: 系统分解为消息队列,消息制造者和消息消费者,一个处理流程可以根据需要拆成多个阶段,阶段之间用队列连接起来,前一个阶段处理的结果放入队列,后一个阶段从队列中获取消息继续处理.
>  *  ⑤. **跨局域网甚至跨城市的通讯**: 比如北京机房与广州机房的应用程序的通信.

#### 2. rabbitmq 有哪些重要的角色? ####

>  *  生产者: 消息的创建者,负责创建和推送数据到消息服务器;
>  *  消费者: 消息的接收方,用于处理数据和确认消息;
>  *  代理: 就是 RabbitMQ 本身,用于扮演“快递”的角色,本身不生产消息,只是扮演“快递”的角色.

#### 3. rabbitmq 有哪些重要的组件? ####

>  *  **ConnectionFactory(连接管理器):** 应用程序与Rabbit之间建立连接的管理器,程序代码中使用.
>  *  **Channel(信道)**: 消息推送使用的通道.
>  *  **Exchange(交换器)**: 用于接受、分配消息.
>  *  **Queue(队列)**: 用于存储生产者的消息.
>  *  **RoutingKey(路由键)**: 用于把生产者的消息分配到交换器上.
>  *  **BindingKey(绑定键)**: 用于把交换器的消息绑定到队列上.

#### 4. rabbitmq 中 vhost 的作用是什么? ####

vhost 可以理解为虚拟 broker,即 mini-RabbitMQ server.其内部均含有独立的 queue、exchange 和 binding 等.但最最重要的是,其拥有独立的权限系统,可以做到 vhost 范围的用户控制.当然,从 RabbitMQ 的全局角度,vhost 可以作为不同权限隔离的手段(一个典型的例子就是不同的应用可以跑在不同的 vhost 中).

#### 5. rabbitmq 的消息是怎么发送的? ####

首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息,客户端和 rabbit server 之间会创建一个 tcp 连接,一旦 tcp 打开并通过了认证(认证就是你发送给 rabbit 服务器的用户名和密码),你的客户端和 RabbitMQ 就创建了一条 amqp 信道(channel),信道是创建在“真实” tcp 上的虚拟连接,amqp 命令都是通过信道发送出去的,每个信道都会有一个唯一的 id,不论是发布消息,订阅队列都是通过这个信道完成的.

#### 6. rabbitmq 怎么保证消息的稳定性? ####

>  *  消息事务;
>  *  消息确认机制.

#### 7. rabbitmq 怎么避免消息丢失? ####

>  *  消息持久化;
>  *  ACK确认机制;
>  *  设置集群镜像模式;
>  *  消息补偿机制.

#### 8. 要保证消息持久化成功的条件有哪些? ####

>  *  声明队列必须设置持久化 durable 设置为 true.
>  *  消息推送投递模式必须设置持久化,deliveryMode 设置为 2(持久);
>  *  消息已经到达持久化交换器;
>  *  消息已经到达持久化队列.

以上四个条件都满足才能保证消息持久化成功。

#### 9. rabbitmq 持久化有什么缺点? ####

持久化的缺地就是降低了服务器的吞吐量,因为使用的是磁盘而非内存存储,从而降低了吞吐量,可尽量使用 ssd 硬盘来缓解吞吐量的问题.

#### 10. rabbitmq 有几种广播类型？ ####

>  *  fanout: 所有bind到此exchange的queue都可以接收消息(纯广播,绑定到RabbitMQ的接受者都能收到消息);
>  *  direct: 通过routingKey和exchange决定的那个唯一的queue可以接收消息;
>  *  topic: 所有符合routingKey(此时可以是一个表达式)的routingKey所bind的queue可以接收消息;
>  *  headers:

#### 11. rabbitmq 怎么实现延迟消息队列? ####

通过消息过期后进入死信交换器,再由交换器转发到延迟消费队列,实现延迟功能;

使用 `RabbitMQ-delayed-message-exchange` 插件实现延迟功能.

#### 12. rabbitmq 集群有什么用? ####

>  *  高可用: 某个服务器出现问题,整个 RabbitMQ 还可以继续使用;
>  *  高容量: 集群可以承载更多的消息量.

#### 13. rabbitmq 节点的类型有哪些? ####

>  *  磁盘节点: 消息会存储到磁盘.
>  *  内存节点: 消息都存储在内存中,重启服务器消息丢失,性能高于磁盘类型.

#### 14. rabbitmq 集群搭建需要注意哪些问题? ####

>  *  各节点之间使用“--link”连接,此属性不能忽略;
>  *  各节点使用的 erlang cookie 值必须相同,此值相当于“秘钥”的功能,用于各节点的认证.
>  *  整个集群中必须包含一个磁盘节点.

#### 15. rabbitmq 每个节点是其他节点的完整拷贝吗? 为什么? ####

不是,原因有以下两个:

>  *  **存储空间的考虑**: 如果每个节点都拥有所有队列的完全拷贝,这样新增节点不但没有新增存储空间,反而增加了更多的冗余数据;
>  *  **性能的考虑**: 如果每条消息都需要完整拷贝到每一个集群节点,那新增节点并没有提升处理消息的能力,最多是保持和单节点相同的性能甚至是更糟.

#### 16. rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况? ####

如果唯一磁盘的磁盘节点崩溃了,则不能进行以下操作:

>  *  不能创建队列;
>  *  不能创建交换器;
>  *  不能创建绑定;
>  *  不能添加用户;
>  *  不能更改权限;
>  *  不能添加和删除集群节点;
>  *  唯一磁盘节点崩溃了,集群是可以保持运行的,但你不能更改任何东西.

#### 17. rabbitmq 对集群节点停止顺序有要求吗? ####

RabbitMQ 对集群的停止的顺序是有要求的,应该先关闭内存节点,最后再关闭磁盘节点.如果顺序恰好相反的话,可能会造成消息的丢失.

#### 18. RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制? ####

可以认为是无限制,因为限制取决于机器的内存,但是消息过多会导致处理效率的下降.

#### 19. 客户端连接到 cluster 中的任意 node 上是否都能正常工作? ####

是的.客户端感觉不到有何不同.

#### 20. 向不存在的 exchange 发 publish 消息会发生什么?向不存在的 queue 执行 consume 动作会发生什么? ####

都会收到 Channel.Close 信令告之不存在(内含原因 404 NOT\_FOUND).

#### 21. routing\_key 和 binding\_key 的最大长度是多少? ####

255 字节.

#### 22. RabbitMQ 允许发送的 message 最大可达多大? ####

根据 AMQP 协议规定,消息体的大小由 64-bit 的值来指定,所以你就可以知道到底能发多大的数据了.

#### 23. “dead letter”queue 死信队列 的用途? ####

当消息被 RabbitMQ server 投递到 consumer 后,但 consumer 却通过 Basic.Reject 进行了拒绝时(同时设置 requeue=false),那么该消息会被放入“dead letter”queue 中.该 queue 可用于排查 message 被 reject 或 undeliver 的原因.

#### 24. 为什么使用消息队列 ####

其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么?

面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处.

说一下消息队列常见的使用场景,比较核心的有 3 个: 解耦、异步、削峰.

#### 25. 常见mq队列及区别 ####

常见的mq队列有ActiveMQ、RabbitMQ、RocketMQ、Kafka,区别可见图:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70][]

#### 26. 如何保证mq数据不丢失? ####

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 1][]

>  *  1️⃣.生产者和mq队列之前传输要使用确认机制,生产者发送消息给mq丢列后,mq要进行接口回调告诉生产者这个数据我已经收到了.如果发送失败生产者要有重试机制进行重新发送.
>  *  2️⃣.mq队列要进行数据的持久化,保证mq挂掉后数据不会丢失.或者保持mq队列的高可用性,防止mq宕机造成数据丢失.
>  *  3️⃣.消费者和mq队列之间也要加入确认机制,待消费者处理完具体的业务后,注意是处理完业务逻辑后,再回调mq,告诉mq我已经处理完了.

#### 27. 如何保证mq幂等性? ####

**保证幂等性的意思就是保证数据不被消费者重复消费,不在在数据库中插入重复的数据,要解决这个问题就要在消费者端入手.**

>  *  1️⃣.进行数据库操作的时候,可以先查下这个数据是否已经存在了,如果存在了进行更新操作,不存在就进行插入操作;
>  *  2️⃣.写入redis:这个比较简单,直接利用redis的set数据类型就可以保证数据不会重复了;
>  *  3️⃣.如果不是数据库业务情景的话,如直接根据得到的数据进行发送邮件或者短信.这种情况的话可以加一个redis的set数据类型进行消重处理,或者用数据库做一个发送的日志记录,用1️⃣的方式去处理.

#### 28. 如何实现mq高可用? ####

每种mq都有实现高可用性的方式,activeMQ和rabbitMQ是通过主从集群的方式实现高可用性的,但是存在一个致命问题就是,当mq队列爆满的时候,主从架构不能横向扩容,因为每个queue保持的数据都是一样的.

下面主要介绍下分布式架构的kafka.  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 2][]

>  *  1️⃣. kafka的一个topic的数据分布在分区(partition)中,而每个partition都分布在不同的broker中,这样就保证了同一个topic的数据分布在不同的机器中;
>  *  2️⃣. kafka每个partition都有一个leader和多个follower,当leader挂了,follower会自动选举出来一个leader,这样就保证了mq的健壮性;
>  *  3️⃣. 生产者和消费者的读写只能通过leader进行,不能读写follower,同时只有当leader的数据同步给follower之后才认为是写成功了,保证数据不丢失.

可以看到,相比主从架构,分布式架构具有更高的可扩展性,可用横向增加partition进行扩容.

#### 29. 如何保证消息队列的高可用? ####

#### RabbitMQ 的高可用性 ####

RabbitMQ 是比较有代表性的,因为是基于主从(非分布式)做高可用性的,我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现.

RabbitMQ 有三种模式: 单机模式、普通集群模式、镜像集群模式.

#### 单机模式 ####

单机模式,就是 Demo 级别的,一般就是你本地启动了玩玩儿的,没人生产环境用单机模式.

#### 普通集群模式(无高可用性) ####

普通集群模式,意思就是在多台机器上启动多个 RabbitMQ 实例,每个机器启动一个.你创建的 queue,只会放在一个 RabbitMQ 实例上,但是每个实例都同步 queue 的元数据(元数据可以认为是 queue 的一些配置信息,通过元数据,可以找到 queue 所在实例).你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从 queue 所在实例上拉取数据过来.  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 3][]

这种方式确实很麻烦,也不怎么好,没做到所谓的分布式,就是个普通集群.因为这导致你要么消费者每次随机连接一个实例然后拉取数据,要么固定连接那个 queue 所在实例消费数据,前者有数据拉取的开销,后者导致单实例性能瓶颈.

而且如果那个放 queue 的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让 RabbitMQ 落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这个 queue 拉取数据.

所以这个事儿就比较尴尬了,**这就没有什么所谓的高可用性,这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个 queue 的读写操作.**

#### 镜像集群模式（高可用性） ####

这种模式,才是所谓的 RabbitMQ 的高可用模式.**跟普通集群模式不一样的是,在镜像集群模式下,你创建的 queue,无论元数据还是 queue 里的消息都会存在于多个实例上,就是说,每个 RabbitMQ 节点都有这个 queue 的一个完整镜像,包含 queue 的全部数据的意思.然后每次你写消息到 queue 的时候,都会自动把消息同步到多个实例的 queue 上**.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 4][]

那么如何开启这个镜像集群模式呢？其实很简单,RabbitMQ 有很好的管理控制台,就是在后台新增一个策略,这个策略是镜像集群模式的策略,指定的时候是可以要求数据同步到所有节点的,也可以要求同步到指定数量的节点,再次创建 queue 的时候,应用这个策略,就会自动将数据同步到其他的节点上去了.

这样的话,好处在于,你任何一个机器宕机了,都没事儿,其它机器(节点)还包含了这个 queue 的完整数据,别的 consumer 都可以到其它节点上去消费数据.坏处在于:第一,这个性能开销也太大了,消息需要同步到所有机器上,导致网络带宽压力和消耗很重! 第二,这么玩儿,不是分布式的,就没有扩展性可言了,如果某个 queue 负载很重,你加机器,新增的机器也包含了这个 queue 的所有数据,并没有办法线性扩展你的 queue.你想,如果这个 queue 的数据量很大,大到这个机器上的容量无法容纳了,此时该怎么办呢?

#### 30. 如何保证消息的顺序性？ ####

#### RabbitMQ会错乱的情况分析: ####

RabbitMQ: 一个 queue,多个 consumer.比如,生产者向 RabbitMQ 里发送了三条数据,顺序依次是 data1/data2/data3,压入的是 RabbitMQ 的一个内存队列,有三个消费者分别从 MQ 中消费这三条数据中的一条,结果消费者2先执行完操作,把 data2 存入数据库,然后是 data1/data3,这不明显乱了.  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 5][]

#### 解决方案1: ####

RabbitMQ: 拆分为多个 queue,每个 queue 对应一个 consumer,就是多一些 queue 而已,确实是麻烦点;或者就一个 queue,但是对应一个 consumer,然后这个 consumer 内部用内存队列做排队,然后分发给底层不同的 worker 来处理.  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 6][]

#### 解决方案2: ####

要保持多个消息之间的时间顺序,首先它们要有一个全局的时间顺序.因此,每个消息在被创建时,都将被赋予一个全局唯一的、单调递增的、连续的序列号(SerialNumber,SN),可以通过一个全局计数器来实现这一点,通过比较两个消息的SN,确定其先后顺序.

#### 31. 如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决? ####

#### 问题分析: ####

该问题其实本质针对的都是说,可能是你的消费端出了问题,不消费了;或者消费的极其极其慢.接着就坑爹了,可能你的消息队列集群的磁盘都快写满了,都没人消费,这个时候怎么办?或者是整个就积压了几个小时,你这个时候怎么办?或者是你积压的时间太长了,导致比如 rabbitmq 设置了消息过期时间后就没了怎么办?

#### mq 中的消息过期失效的解决办法 ####

假设你用的是 RabbitMQ,RabbtiMQ 是可以设置过期时间的,也就是 TTL.如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉,这个数据就没了.

这个情况下,就不是说要增加 consumer 消费积压的消息,因为实际上没啥积压,而是丢了大量的消息.我们可以采取一个方案,就是**批量重导**,就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上12点以后,用户都睡觉了,这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入 mq 里面去,把白天丢的数据给他补回来,也只能是这样了.

假设 1 万个订单积压在 mq 里面,没有处理,其中 1000 个订单都丢了,**你只能手动写程序把那 1000 个订单给查出来,手动发到 mq 里去再补一次.**

#### mq 都快写满了的解决办法 ####

如果是消息积压在 mq 里,那么如果你很长时间都没处理掉,此时导致 mq 都快写满了,咋办?这个还有别的办法吗？没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,消费一个丢弃一个,都不要了,快速消费掉所有的消息,然后走第二个方案,到了晚上再补数据吧.

#### 大量消息在 mq 里积压了几个小时了还没解决的解决办法 ####

几千万条数据在 MQ 里积压了七八个小时,从下午 4 点多,积压到了晚上 11 点多.这个时候要不然就是修复 consumer 的问题,让它恢复消费速度,然后傻傻的等待几个小时消费完毕,这个肯定不能在面试的时候说吧.

一个消费者一秒是 1000 条,一秒 3 个消费者是 3000 条,一分钟就是 18 万条.所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概 1 小时的时间才能恢复过来.

**一般这个时候,只能临时紧急扩容了,**具体操作步骤和思路如下:

> 1️⃣. 先修复 consumer 的问题,确保其恢复消费速度,然后将现有 cnosumer 都停掉;
> 
> 2️⃣. 再新建一个 topic,partition 是原来的 10 倍,临时建立好原先 10 倍的 queue 数量;
> 
> 3️⃣. 然后写一个临时的分发数据的 consumer 程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的 10 倍数量的 queue;
> 
> 4️⃣. 接着临时征用 10 倍的机器来部署 consumer,每一批 consumer 消费一个临时 queue 的数据.这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍,以正常的 10 倍速度来消费数据;
> 
> 5️⃣. 等快速消费完积压数据之后,得恢复原先部署的架构,重新用原先的 consumer 机器来消费消息.

#### 32. 如果让你写一个消息队列,该如何进行架构设计?说一下你的思路. ####

其实聊到这个问题,一般面试官要考察两块:

>  *  你有没有对某一个消息队列做过较为深入的原理的了解,或者从整体了解把握住一个消息队列的架构原理;
>  *  看看你的设计能力,给你一个常见的系统,就是消息队列系统,看看你能不能从全局把握一下整体架构设计,给出一些关键点出来.

说实话,问类似问题的时候,大部分人基本都会懵,因为平时从来没有思考过类似的问题,大多数人就是平时埋头用,从来不去思考背后的一些东西.类似的问题,比如,如果让你来设计一个 Spring 框架你会怎么做? 如果让你来设计一个 Dubbo 框架你会怎么做? 如果让你来设计一个 MyBatis 框架你会怎么做?

#### 答案: ####

其实回答这类问题,说白了,**不求你看过那技术的源码,起码你要大概知道那个技术的基本原理、核心组成部分、基本架构构成,然后参照一些开源的技术把一个系统设计出来的思路说一下就好.**

比如说这个消息队列系统,我们从以下几个角度来考虑一下:

>  *  1️⃣. **首先这个 mq 得支持可伸缩性吧,就是需要的时候快速扩容,就可以增加吞吐量和容量**,那怎么搞?**设计个分布式的系统呗**,参照一下 kafka 的设计理念,broker -> topic -> partition,每个 partition 放一个机器,就存一部分数据.如果现在资源不够了,简单啊,给 topic 增加 partition,然后做数据迁移,增加机器,不就可以存放更多数据,提供更高的吞吐量了?
>  *  2️⃣. **其次你得考虑一下这个 mq 的数据要不要持久化到磁盘**吧?那肯定要了,持久化到磁盘才能保证进程挂了数据也不会丢失,那持久化到磁盘的时候怎么持久化啊？顺序写,这样就没有磁盘随机读写的寻址开销,磁盘顺序读写的性能是很高的,这就是 kafka 的思路.
>  *  3️⃣. **其次你考虑一下你的 mq 的可用性**,这个事儿,具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制.多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务.
>  *  4️⃣. **能不能支持数据 0 丢失**啊?可以的,参考我们之前说的那个 kafka 数据零丢失方案.

mq 肯定是很复杂的,面试官问你这个问题,其实是个开放题,他就是看看你有没有从架构角度整体构思和设计的思维以及能力.确实这个问题可以刷掉一大批人,因为大部分人平时不思考这些东西.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/d2406a10a00d48e3846bdee2515580ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/7c3099ad3e6b48a3a06b71e1793c2ba2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/92d9f311d0254453abe906ff3ccc90d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/193de98caf174b34b0a99f026eeacc4f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/9902287b72354a46821695c6c397b620.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/ec114a316d9a4161bd2bf51283798170.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/20/7307a605ce1b40dd86c6ba0a00cefe6b.png