RabbitMQ 01- 概念详解

忘是亡心i 2022-12-17 03:26 178阅读 0赞

> 本篇包含了RabbitMQ概念的一些东西，下篇会整理出SpringBoot结合RabbitMQ的使用案例。

### 文章目录 ###

*   *   *  一、MQ概述
         *   *  1.什么是消息
             *  2.什么是消息队列
             *  3.MQ的特点
         *  二、MQ适用场景
         *   *  1.解耦
             *  2.异步
             *  3.削峰
             *  4.使用MQ优缺点
         *  三、MQ选型对比
         *   *  1.Kafka
             *  2.RabbitMQ
             *  3.RocketMQ
             *  4.选型和对比
         *  四、RabbitMQ概述
         *   *  1.概念
             *  2.特点
             *  3.概念模型
         *  五.交换机类型
         *   *  1.Direct Exchange
             *  2.Fanout Exchange
             *  3.Topic Exchange
             *  4. Headers Exchanges

### 一、MQ概述 ###

#### 1.什么是消息 ####

我们都知道RabbitMQ是一款消息队列中间件，那如何理解消息呢？

消息（Message）是指在应用间传递的数据。  
消息可以非常简单，比如只包含文本字符串，也可以更复杂，比如包含对象和JSON数据。

#### 2.什么是消息队列 ####

消息队列（Message Queue）是一种应用间的通讯方式，也可以理解为是保存消息的的一个容器。消息发布者只管把消息发布到MQ而不用管谁来取，消息使用者只管从MQ中取消息而不用管是谁发布的。

#### 3.MQ的特点 ####

*  先进先出  
    不能先进先出，都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。而且，最重要的是，数据是只有一条数据在使用中。 这也是MQ在诸多场景被使用的原因。
 *  发布订阅  
    发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率，这样的应用场景非常广泛。
 *  持久化  
    持久化确保MQ的使用不只是一个部分场景的辅助工具，而是让MQ能像数据库一样存储核心的数据。
 *  分布式  
    在现在大流量、大数据的使用场景下，只支持单体应用的服务器软件基本是无法使用的，支持分布式的部署，才能被广泛使用。而且，MQ的定位就是一个高性能的中间件。

从以上描述可以看出消息队列是一种应用间的异步协作机制，那什么时候需要使用MQ呢？

### 二、MQ适用场景 ###

#### 1.解耦 ####

> 场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。

![在这里插入图片描述][20201021165803480.png_pic_center]

**传统模式的缺点：**

*  假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。
 *  订单系统与库存系统耦合。

**引入消息队列：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center]

*  订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
 *  库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
 *  假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。
 *  为了保证库存肯定有，可以将队列大小设置成库存数量，或者采用其他方式解决。

#### 2.异步 ####

> 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式。

*  串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 1]

*  并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 2]

*  引入消息队列，将不是必须的业务逻辑，异步处理。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 3]

#### 3.削峰 ####

> 流量削锋也是消息队列中的常用场景，一般在秒杀或抢购活动中使用广泛。

> 应用场景：系统其他时间A系统每秒请求量就100个，系统可以稳定运行。系统每天晚间八点有秒杀活动，每秒并发请求量增至1万条，但是系统最大的处理能力只能每秒处理1000个请求，于是系统崩溃，服务器宕机。

*  传统架构：大量用户（100万用户）通过浏览器在晚上八点高峰期同时参与秒杀活动。大量的请求涌入我们的系统中，高峰期达到每秒钟5000个请求，大量的请求打到MySQL上，每秒钟预计执行3000条SQL。但是一般的MySQL每秒钟扛住2000个请求就不错了，如果达到3000个请求的话可能MySQL直接就瘫痪了，从而系统无法被使用。  
    但是高峰期过了之后，就成了低峰期，可能也就1万用户访问系统，每秒的请求数量也就50个左右，整个系统几乎没有任何压力。
 *  引入MQ：100万用户在高峰期的时候，每秒请求有5000个请求左右，将这5000请求写入MQ里面，系统A每秒最多只能处理2000请求，因为MySQL每秒只能处理2000个请求。系统A从MQ中慢慢拉取请求，每秒就拉取2000个请求，不要超过自己每秒能处理的请求数量即可。MQ，每秒5000个请求进来，结果只有2000个请求出去，所以在秒杀期间（将近一小时）可能会有几十万或者几百万的请求积压在MQ中。这个短暂的高峰期积压是没问题的，因为高峰期过了之后，每秒就只有50个请求进入MQ了，但是系统还是按照每秒2000个请求的速度在处理，所以说，只要高峰期一过，系统就会快速将积压的消息消费掉。我们在此计算一下，每秒在MQ积压3000条消息，1分钟会积压18万，1小时积压1000万条消息，高峰期过后，1个多小时就可以将积压的1000万消息消费掉。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 4]

#### 4.使用MQ优缺点 ####

**优点**

优点就是以上的那些场景应用，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

**缺点**

*  系统的可用性降低：系统引入的外部依赖越多，系统越容易挂掉，本来只是A系统调用BCD三个系统接口就好，ABCD四个系统不报错整个系统会正常运行。引入了MQ之后，虽然ABCD系统没出错，但MQ挂了以后，整个系统也会崩溃。
 *  系统的复杂性提高：引入了MQ之后，需要考虑的问题也变得多了，如何保证消息没有重复消费？如何保证消息不丢失？怎么保证消息传递的顺序？
 *  一致性问题：A系统发送完消息直接返回成功，但是BCD系统之中若有系统写库失败，则会产生数据不一致的问题。

那么，消息中间件性能究竟哪家强?

### 三、MQ选型对比 ###

#### 1.Kafka ####

Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

#### 2.RabbitMQ ####

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

#### 3.RocketMQ ####

RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 5]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 6]

#### 4.选型和对比 ####

*  从社区活跃度  
    按照目前网络上的资料，RabbitMQ 、ActiveMQ、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。
 *  持久化消息比较  
    ZeroMQ 不支持，ActiveMQ 和RabbitMQ 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。
 *  综合技术实现  
    可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系 统等等。
    
    RabbitMQ / Kafka 最好，ActiveMQ 次之，ZeroMQ 最差。当然ZeroMQ 也可以做到，不过自己必须手 动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
 *  高并发  
    毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。
 *  定位  
    Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMQ 。
 *  选型最后总结  
    如果我们系统中已经有选择 Kafka ，或者 RabbitMQ ，并且完全可以满足现在的业务，建议就不用重复去增加和造轮子。
    
    可以在 Kafka 和 RabbitMQ 中选择一个适合自己团队和业务的，这个才是最重要的。但是毋庸置疑现阶段，综合考虑没有第三选择。

> 参考  
> Kafka、RabbitMQ、RocketMQ等消息中间件的介绍和对比  
> https://blog.csdn.net/yunfeng482/article/details/72856762

### 四、RabbitMQ概述 ###

#### 1.概念 ####

RabbitMQ是一个由Erlang语言开发的AMQP的开源实现。

RabbitMQ最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

> [移步官网][Link 1]

AMQP：Advanced Message Queue，高级消息队列协议，它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。

Erlang是一种面向并发的通用编程语言，它由瑞典电信设备制造商爱立信所辖的计算机科学研究室开发，目的是创造一种可以应付大规模并发行为的编程语言和执行环境。

#### 2.特点 ####

*  可靠性（Reliability）  
    RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。
 *  灵活的路由（Flexible Routing）  
    在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
 *  消息集群（Clustering）  
    多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
 *  高可用（Highly Available Queues）  
    队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
 *  多种协议（Multi-protocol）  
    RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。
 *  多语言客户端（Many Clients）  
    RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。
 *  管理界面（Management UI）  
    RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。
 *  跟踪机制（Tracing）  
    如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。
 *  插件机制（Plugin System）  
    RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

#### 3.概念模型 ####

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

*  Message  
    消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。
 *  Publisher  
    消息的生产者，也是一个向交换器发布消息的客户端应用程序。
 *  Exchange  
    交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
 *  Binding  
    绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
 *  Queue  
    消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
 *  Connection  
    网络连接，比如一个TCP连接。
 *  Channel  
    信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
 *  Consumer  
    消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
 *  Virtual Host  
    虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
 *  Broker  
    表示MQ服务器实体。

### 五.交换机类型 ###

#### 1.Direct Exchange ####

> 直连交换机，需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键“abc”，则只有被标记为“abc”的消息才被转发，不会转发abc.def，也不会转发dog.ghi，只会转发abc。

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

#### 2.Fanout Exchange ####

> 广播交换机，将消息路由给绑定到它身上的所有队列，与绑定的路由键无关。  
> 如果N个队列绑定到某个扇型交换机上，当有消息发送给此扇型交换机时，交换机会将消息的拷贝分别发送给这所有的N个队列。扇型用来交换机处理消息的广播路由（broadcast routing）。所以扇形交换机主要做的就是广播消息。

应用场景：

*  大规模多用户在线（MMO）游戏可以使用它来处理排行榜更新等全局事件。
 *  体育新闻网站可以用它来近乎实时地将比分更新分发给移动客户端。
 *  分发系统使用它来广播各种状态和配置更新。
 *  在群聊的时候，它被用来分发消息给参与群聊的用户。（AMQP没有内置presence的概念，因此XMPP可能会是个更好的选择）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 9]

#### 3.Topic Exchange ####

> 主题交换机，将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号“\#”匹配一个或多个词，符号“”匹配不多不少一个词。因此“abc.\#”能够匹配到“abc.def.ghi”，但是“abc.” 只会匹配到“abc.def”。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 10]

#### 4. Headers Exchanges ####

> 头交换机，有时消息的路由操作会涉及到多个属性，此时使用消息头就比用路由键更容易表达，头交换机（headers exchange）就是为此而生的。
> 
> 头交换机使用多个消息属性来代替路由键建立路由规则。通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。

我们可以绑定一个队列到头交换机上，并给他们之间的绑定使用多个用于匹配的头（header）。

在头交换机中需要考虑的是需要部分匹配还是全部匹配。相比较于直达交换机，头交换机的优势是匹配的规则不被限定为字符串，头交换机需要在队列绑定的规则中指定消息头和匹配的规则。

匹配规则x-match有下列两种类型：

*  x-match = all ：表示所有的键值对都匹配才能接受到消息
 *  x-match = any ：表示只要有键值对匹配就能接受到消息

就是在指定消息头（键值对）时，添加”x-match”参数，当”x-match”设置为“any”时，消息头的任意一个值被匹配就可以满足条件，而当”x-match”设置为“all”的时候，就需要消息头的所有值都匹配成功。

头交换机可以视为直连交换机的另一种表现形式。头交换机能够像直连交换机一样工作，不同之处在于头交换机的路由规则是建立在头属性值之上，而不是路由键。路由键必须是一个字符串，而头属性值则没有这个约束，它们甚至可以是整数或者哈希值（字典）等。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 11]

生产者发送一个含有消息头为 \{“key2”：“value2”\} 的消息，到头交换机后，交换机会根据队列绑定消息头中“x-match”的匹配规则（就是上面介绍的all、any的规则），把消息投递给满足消息头匹配规则的队列中，然后再投递给监听该队列的用户。

这里的匹配就是消息头（键值对）模式，这个模式就是头交换机。

> 文参考  
> Hai Xiang  
> https://www.cnblogs.com/haixiang/p/10199754.html

> Anumbrella  
> https://blog.csdn.net/Anumbrella/article/details/80172515

> https://www.cnblogs.com/linyufeng/p/9885020.html

> 预流： https://www.jianshu.com/p/79ca08116d57/

> BraveSoul360：ttps://blog.csdn.net/yunfeng482/article/details/72856762

> 架构师梵心 ：https://www.cnblogs.com/fancyn/p/12560793.html

> 关注微信公众号【程序媛琬淇】，专注分享Java干货，给你意想不到的收获。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 12]

[20201021165803480.png_pic_center]: /images/20221123/6dd59f01008d46dc85512ebfa63f1ac4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/aa80f30b408b4d0aa95c78c8e0cc66a9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/d9dcebd62a16464ba1043d20e363551f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/e638e1915d67440ea3f385cd169c4ad6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/dfe433957bb14f62a6de5a8f83e02f72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/431b01cf01c742fd885b4d5a1367f526.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/808793bfc3164b199f12b685a55d438a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/e600a78d5c9d4c8ab1f5e7b16aa1165f.png
[Link 1]: https://www.rabbitmq.com/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/3333421b125b4f928f8a487f12a9364d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/0621d9fdc2df4eeb98ee72c490b08c9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/89afb9ad95de4c738cfc7e9c847fc096.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221123/2808fc3afbd24af1871e8e83b8768c31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221123/1a7041291dc348508ca6906923c730e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzA5NDM2MQ_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221123/57d5226c636d42259dd375b461e54805.png