浅谈消息队列及常见的消息中间件

梦里梦外; 2022-05-13 04:58 226阅读 0赞

# 前言 #

**消息队列** 已经逐渐成为企业应用系统 **内部通信** 的核心手段。它具有 **低耦合**、**可靠投递**、**广播**、**流量控制**、**最终一致性** 等一系列功能。

当前使用较多的 **消息队列** 有 `RabbitMQ`、`RocketMQ`、`ActiveMQ`、`Kafka`、`ZeroMQ`、`MetaMQ` 等，而部分 **数据库** 如 `Redis`、`MySQL` 以及 `phxsql` 也可实现消息队列的功能。

![16479c8ed095ffed_w_989_h_290_f_webp_s_10430][]

# 正文 #

## 1. 消息队列概述 ##

**消息队列** 是指利用 **高效可靠** 的 **消息传递机制** 进行与平台无关的 **数据交流**，并基于 **数据通信** 来进行分布式系统的集成。

![16479c8e7c77109d_w_623_h_242_f_webp_s_6046][]

通过提供 **消息传递** 和 **消息排队** 模型，它可以在 **分布式环境** 下提供 **应用解耦**、**弹性伸缩**、**冗余存储**、**流量削峰**、**异步通信**、**数据同步** 等等功能，其作为 **分布式系统架构** 中的一个重要组件，有着举足轻重的地位。

## 2. 消息队列的特点 ##

### 2.1. 采用异步处理模式 ###

**消息发送者** 可以发送一个消息而无须等待响应。**消息发送者** 将消息发送到一条 **虚拟的通道**（**主题** 或 **队列**）上，**消息接收者** 则 **订阅** 或是 **监听** 该通道。一条信息可能最终转发给 **一个或多个** 消息接收者，这些接收者都无需对 **消息发送者** 做出 **同步回应**。整个过程都是 **异步的**。

### 2.2. 应用系统之间解耦合 ###

主要体现在如下两点：

1.  发送者和接受者不必了解对方、只需要 **确认消息**；
2.  发送者和接受者 **不必同时在线**。

比如在线交易系统为了保证数据的 **最终一致**，在 **支付系统** 处理完成后会把 **支付结果** 放到 **消息中间件** 里，通知 **订单系统** 修改 **订单支付状态**。两个系统是通过消息中间件解耦的。

## 3. 消息队列的传递服务模型 ##

消息队列的 **传递服务模型** 如下图所示：

![16479c8e7c831340_w_653_h_406_f_jpeg_s_51288][]

## 4. 消息队列的的传输模式 ##

### 4.1. 点对点模型 ###

**点对点模型** 用于 **消息生产者** 和 **消息消费者** 之间 **点到点** 的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个 **队列**（`Queue`），在消息传递给消费者之前它被 **存储** 在这个队列中。**队列消息** 可以放在 **内存** 中也可以 **持久化**，以保证在消息服务出现故障时仍然能够传递消息。

传统的点对点消息中间件通常由 **消息队列服务**、**消息传递服务**、**消息队列** 和 **消息应用程序接口** `API` 组成，其典型的结构如下图所示。

![16479c8e7c97b0c3_w_910_h_408_f_jpeg_s_68819][]

**特点：**

1.  每个消息只用一个消费者；
2.  发送者和接受者没有时间依赖；
3.  接受者确认消息接受和处理成功。

**示意图如下所示：**

![16479c8e7c89962f_w_832_h_126_f_jpeg_s_14475][]

### 4.2. 发布/订阅模型（Pub/Sub） ###

**发布者/订阅者** 模型支持向一个特定的 **消息主题** 生产消息。`0` 或 **多个订阅者** 可能对接收来自 **特定消息主题** 的消息感兴趣。

在这种模型下，发布者和订阅者彼此不知道对方，就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在 **发布者** 和 **订阅者** 之间存在 **时间依赖性**。发布者需要建立一个 **订阅**（`subscription`），以便能够消费者订阅。**订阅者** 必须保持 **持续的活动状态** 并 **接收消息**。

在这种情况下，在订阅者 **未连接时**，发布的消息将在订阅者 **重新连接** 时 **重新发布**，如下图所示：

![16479c8e7faf60a5_w_492_h_268_f_jpeg_s_16077][]

**特性：**

1.  每个消息可以有多个订阅者；
2.  客户端只有订阅后才能接收到消息；
3.  持久订阅和非持久订阅。

> 注意：  
> 1. 发布者和订阅者有时间依赖：接受者和发布者只有建立订阅关系才能收到消息；  
> 2. 持久订阅：订阅关系建立后，消息就不会消失，不管订阅者是否都在线；  
> 3. 非持久订阅：订阅者为了接受消息，必须一直在线。  
> 当只有一个订阅者时约等于点对点模式

## 5. 消息队列应用场景 ##

当你需要使用 **消息队列** 时，首先需要考虑它的必要性。可以使用消息队列的场景有很多，最常用的几种，是做 **应用程序松耦合**、**异步处理模式**、**发布与订阅**、**最终一致性**、**错峰流控** 和 **日志缓冲** 等。反之，如果需要 **强一致性**，关注业务逻辑的处理结果，则使用 `RPC` 显得更为合适。

### 5.1. 异步处理 ###

**非核心** 流程 **异步化**，减少系统 **响应时间**，提高 **吞吐量**。例如：**短信通知**、**终端状态推送**、`App` **推送**、**用户注册** 等。

**消息队列** 一般都内置了 **高效的通信机制**，因此也可以用于单纯的消息通讯，比如实现 **点对点消息队列** 或者 **聊天室** 等。

#### 应用案例 ####

网站用户注册，注册成功后会过一会发送邮件确认或者短息。

![16479c8e800ce905_w_541_h_300_f_jpeg_s_16288][]

### 5.2. 系统解耦 ###

*  系统之间不是 **强耦合的**，**消息接受者** 可以随意增加，而不需要修改 **消息发送者的代码**。**消息发送者** 的成功不依赖 **消息接受者**（比如：有些银行接口不稳定，但调用方并不需要依赖这些接口）。
 *  **不强依赖** 于非本系统的核心流程，对于 **非核心流程**，可以放到消息队列中让 **消息消费者** 去按需消费，而 **不影响核心主流程**。

### 5.3. 最终一致性 ###

**最终一致性** 不是 **消息队列** 的必备特性，但确实可以依靠 **消息队列** 来做 **最终一致性** 的事情。

*  **先写消息再操作**，确保操作完成后再修改消息状态。**定时任务补偿机制** 实现消息 **可靠发送接收**、业务操作的可靠执行，要注意 **消息重复** 与 **幂等设计**。
 *  所有不保证 `100%` **不丢消息** 的消息队列，理论上无法实现 **最终一致性**。

> 像 `Kafka` 一类的设计，在设计层面上就有 **丢消息** 的可能（比如 **定时刷盘**，如果掉电就会丢消息）。哪怕只丢千分之一的消息，业务也必须用其他的手段来保证结果正确。

### 5.4. 广播 ###

**生产者/消费者** 模式，只需要关心消息是否 **送达队列**，至于谁希望订阅和需要消费，是 **下游** 的事情，无疑极大地减少了开发和联调的工作量。

![16479c8ea267f536_w_595_h_346_f_webp_s_10596][]

### 5.5. 流量削峰和流控 ###

当 **上下游系统** 处理能力存在差距的时候，利用 **消息队列** 做一个通用的 **“漏斗”**，进行 **限流控制**。在下游有能力处理的时候，再进行分发。

> 举个例子：用户在支付系统成功结账后，订单系统会通过短信系统向用户推送扣费通知。  
> **短信系统** 可能由于 **短板效应**，速度卡在 **网关** 上（每秒几百次请求），跟 **前端的并发量** 不是一个数量级。  
> 于是，就造成 **支付系统** 和 **短信系统** 的处理能力出现差异化。

然而用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过 **协商**、**滑动窗口** 等复杂的方案也不是说不能实现。但 **系统复杂性** 指数级增长，势必在 **上游** 或者 **下游** 做 **存储**，并且要处理 **定时**、**拥塞** 等一系列问题。而且每当有 **处理能力有差距** 的时候，都需要 **单独** 开发一套逻辑来维护这套逻辑。

所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。

#### 应用案例 ####

1.  把消息队列当成可靠的 **消息暂存地**，进行一定程度的 **消息堆积**；
2.  定时进行消息投递，比如模拟 **用户秒杀** 访问，进行 **系统性能压测**。

![16479c8ea3e6231a_w_587_h_401_f_jpeg_s_24739][]

### 5.6. 日志处理 ###

将消息队列用在 **日志处理** 中，比如 `Kafka` 的应用，解决 **海量日志** 传输和缓冲的问题。

#### 应用案例 ####

把日志进行集中收集，用于计算 `PV`、**用户行为分析** 等等。

![16479c8ea41e864b_w_648_h_247_f_jpeg_s_18958][]

### 5.7. 消息通讯 ###

消息队列一般都内置了 **高效的通信机制**，因此也可以用于单纯的 **消息通讯**，比如实现 **点对点消息队列** 或者 **聊天室** 等。

## 6. 消息队列的推拉模型 ##

### 6.1. Push推消息模型 ###

**消息生产者** 将消息发送给 **消息队列**，**消息队列** 又将消息推给 **消息消费者**。

### 6.2. Pull拉消息模型 ###

**消费者** 请求 **消息队列** 接受消息，**消息生产者** 从 **消息队列** 中拉该消息。

### 6.3. 两种类型的区别 ###

![16479c8ea4b19ea9_w_581_h_574_f_jpeg_s_120422][]

## 7. 消息队列技术对比 ##

本部分主要介绍四种常用的消息队列（`ActiveMQ` / `RabbitMQ` / `RocketMQ` / `Kafka`）的主要特性、优点、缺点。

### 7.1. ActiveMQ ###

`ActiveMQ` 是由 `Apache` 出品，`ActiveMQ` 是一个完全支持`JMS1.1` 和 `J2EE 1.4` 规范的 `JMS Provider` 实现。它非常快速，支持 **多种语言的客户端** 和 **协议**，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

![16479c8ea7cdc2c0_w_568_h_552_f_png_s_41834][]

#### (a) 主要特性 ####

1.  **服从JMS规范**：`JMS` 规范提供了良好的标准和保证，包括：**同步** 或 **异步** 的消息分发，一次和仅一次的消息分发，**消息接收** 和 **订阅** 等等。遵从 `JMS` 规范的好处在于，不论使用什么 `JMS` 实现提供者，这些基础特性都是可用的；
2.  **连接灵活性**：`ActiveMQ` 提供了广泛的 **连接协议**，支持的协议有：`HTTP/S`，`IP` **多播**，`SSL`，`TCP`，`UDP` 等等。对众多协议的支持让 `ActiveMQ` 拥有了很好的灵活性；
3.  **支持的协议种类多**：`OpenWire`、`STOMP`、`REST`、`XMPP`、`AMQP`；
4.  **持久化插件和安全插件**：`ActiveMQ` 提供了 **多种持久化** 选择。而且，`ActiveMQ` 的安全性也可以完全依据用户需求进行 **自定义鉴权** 和 **授权**；
5.  **支持的客户端语言种类多**：除了 `Java` 之外，还有：`C/C++`，`.NET`，`Perl`，`PHP`，`Python`，`Ruby`；
6.  **代理集群**：多个 `ActiveMQ` **代理** 可以组成一个 **集群** 来提供服务；
7.  **异常简单的管理**：`ActiveMQ` 是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以 **监控** `ActiveMQ` 不同层面的数据，包括使用在 `JConsole` 或者在 `ActiveMQ` 的 `Web Console` 中使用 `JMX`。通过处理 `JMX` 的告警消息，通过使用 **命令行脚本**，甚至可以通过监控各种类型的 **日志**。

#### (b) 部署环境 ####

`ActiveMQ` 可以运行在 `Java` 语言所支持的平台之上。使用 `ActiveMQ` 需要：

*  `Java JDK`
 *  `ActiveMQ` 安装包

#### (c) 优点 ####

1.  **跨平台** (`JAVA` 编写与平台无关，`ActiveMQ` 几乎可以运行在任何的 `JVM` 上)；
2.  可以用 `JDBC`：可以将 **数据持久化** 到数据库。虽然使用 `JDBC` 会降低 `ActiveMQ` 的性能，但是数据库一直都是开发人员最熟悉的存储介质；
3.  支持 `JMS` 规范：支持 `JMS` 规范提供的 **统一接口**;
4.  支持 **自动重连** 和 **错误重试机制**；
5.  有安全机制：支持基于 `shiro`，`jaas` 等多种 **安全配置机制**，可以对 `Queue/Topic` 进行 **认证和授权**；
6.  监控完善：拥有完善的 **监控**，包括 `Web Console`，`JMX`，`Shell` 命令行，`Jolokia` 的 `RESTful API`；
7.  界面友善：提供的 `Web Console` 可以满足大部分情况，还有很多 **第三方的组件** 可以使用，比如 `hawtio`；

#### (d) 缺点 ####

1.  社区活跃度不及 `RabbitMQ` 高；
2.  根据其他用户反馈，会出莫名其妙的问题，会 **丢失消息**；
3.  目前重心放到 `activemq 6.0` 产品 `Apollo`，对 `5.x` 的维护较少；
4.  不适合用于 **上千个队列** 的应用场景；

### 7.2. RabbitMQ ###

`RabbitMQ` 于 `2007` 年发布，是一个在 `AMQP` (**高级消息队列协议**)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

![16479c8ece3b5d7a_w_635_h_298_f_png_s_36428][]

#### (a) 主要特性 ####

1.  **可靠性**：提供了多种技术可以让你在 **性能** 和 **可靠性** 之间进行 **权衡**。这些技术包括 **持久性机制**、**投递确认**、**发布者证实** 和 **高可用性机制**；
2.  **灵活的路由**：消息在到达队列前是通过 **交换机** 进行 **路由** 的。`RabbitMQ` 为典型的路由逻辑提供了 **多种内置交换机** 类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做 `RabbitMQ` 的 **插件** 来使用；
3.  **消息集群**：在相同局域网中的多个 `RabbitMQ` 服务器可以 **聚合** 在一起，作为一个独立的逻辑代理来使用；
4.  **队列高可用**：队列可以在集群中的机器上 **进行镜像**，以确保在硬件问题下还保证 **消息安全**；
5.  **支持多种协议**：支持 **多种消息队列协议**；
6.  **支持多种语言**：用 `Erlang` 语言编写，支持只要是你能想到的 **所有编程语言**；
7.  **管理界面**： `RabbitMQ` 有一个易用的 **用户界面**，使得用户可以 **监控** 和 **管理** 消息 `Broker` 的许多方面；
8.  **跟踪机制**：如果 **消息异常**，`RabbitMQ` 提供消息跟踪机制，使用者可以找出发生了什么；
9.  **插件机制**：提供了许多 **插件**，来从多方面进行扩展，也可以编写自己的插件。

#### (b) 部署环境 ####

`RabbitMQ` 可以运行在 `Erlang` 语言所支持的平台之上，包括 `Solaris`，`BSD`，`Linux`，`MacOSX`，`TRU64`，`Windows` 等。使用 `RabbitMQ` 需要：

*  `ErLang` 语言包
 *  `RabbitMQ` 安装包

#### (c) 优点 ####

1.  由于 `Erlang` 语言的特性，消息队列性能较好，支持 **高并发**；
2.  健壮、稳定、易用、**跨平台**、支持 **多种语言**、文档齐全；
3.  有消息 **确认机制** 和 **持久化机制**，可靠性高；
4.  高度可定制的 **路由**；
5.  **管理界面** 较丰富，在互联网公司也有较大规模的应用，社区活跃度高。

#### (d) 缺点 ####

1.  尽管结合 `Erlang` 语言本身的并发优势，性能较好，但是不利于做 **二次开发和维护**；
2.  实现了 **代理架构**，意味着消息在发送到客户端之前可以在 **中央节点** 上排队。此特性使得 `RabbitMQ` 易于使用和部署，但是使得其 **运行速度较慢**，因为中央节点 **增加了延迟**，**消息封装后** 也比较大；
3.  需要学习 **比较复杂** 的 **接口和协议**，学习和维护成本较高。

### 7.3. RocketMQ ###

`RocketMQ` 出自 **阿里** 的开源产品，用 `Java` 语言实现，在设计时参考了 `Kafka`，并做出了自己的一些改进，**消息可靠性上** 比 `Kafka` 更好。`RocketMQ` 在阿里内部被广泛应用在 **订单**，**交易**，**充值**，**流计算**，**消息推送**，**日志流式处理**，`binglog` **分发** 等场景。

#### (a) 主要特性 ####

![16479c8ec333c809][]

1.  基于 **队列模型**：具有 **高性能**、**高可靠**、**高实时**、**分布式** 等特点；
2.  `Producer`、`Consumer`、**队列** 都支持 **分布式**；
3.  `Producer` 向一些队列轮流发送消息，**队列集合** 称为 `Topic`。`Consumer` 如果做 **广播消费**，则一个 `Consumer` 实例消费这个 `Topic` 对应的 **所有队列**；如果做 **集群消费**，则 **多个** `Consumer` 实例 **平均消费** 这个 `Topic` 对应的队列集合；
4.  能够保证 **严格的消息顺序**；
5.  提供丰富的 **消息拉取模式**；
6.  高效的订阅者 **水平扩展**能力；
7.  **实时** 的 **消息订阅机制**；
8.  亿级 **消息堆积** 能力；
9.  较少的外部依赖。

#### (b) 部署环境 ####

`RocketMQ` 可以运行在 `Java` 语言所支持的平台之上。使用 `RocketMQ` 需要：

*  `Java JDK`
 *  安装 `git`、`Maven`
 *  `RocketMQ` 安装包

#### (c) 优点 ####

1.  **单机** 支持 `1` 万以上 **持久化队列**；
2.  `RocketMQ` 的所有消息都是 **持久化的**，先写入系统 `PAGECACHE`，然后 **刷盘**，可以保证 **内存** 与 **磁盘** 都有一份数据，而 **访问** 时，直接 **从内存读取**。
3.  模型简单，接口易用（`JMS` 的接口很多场合并不太实用）；
4.  **性能非常好**，可以允许 **大量堆积消息** 在 `Broker` 中；
5.  支持 **多种消费模式**，包括 **集群消费**、**广播消费**等；
6.  各个环节 **分布式扩展设计**，支持 **主从** 和 **高可用**；
7.  开发度较活跃，版本更新很快。

#### (d) 缺点 ####

1.  支持的 **客户端语言** 不多，目前是 `Java` 及 `C++`，其中 `C++` 还不成熟；
2.  `RocketMQ` 社区关注度及成熟度也不及前两者；
3.  没有 `Web` 管理界面，提供了一个 `CLI` (命令行界面) 管理工具带来 **查询**、**管理** 和 **诊断各种问题**；
4.  没有在 `MQ` 核心里实现 `JMS` 等接口；

### 7.4. Kafka ###

`Apache Kafka` 是一个 **分布式消息发布订阅** 系统。它最初由 `LinkedIn` 公司基于独特的设计实现为一个 **分布式的日志提交系统** (`a distributed commit log`)，之后成为 `Apache` 项目的一部分。`Kafka` **性能高效**、**可扩展良好** 并且 **可持久化**。它的 **分区特性**，**可复制** 和 **可容错** 都是其不错的特性。

![16479c8ec4ba760a_w_708_h_364_f_png_s_55959][]

#### (a) 主要特性 ####

1.  **快速持久化**：可以在 `O(1)` 的系统开销下进行 **消息持久化**；
2.  **高吞吐**：在一台普通的服务器上既可以达到 `10W/s` 的 **吞吐速率**；
3.  **完全的分布式系统**：`Broker`、`Producer` 和 `Consumer` 都原生自动支持 **分布式**，自动实现 **负载均衡**；
4.  支持 **同步** 和 **异步** 复制两种 **高可用机制**；
5.  支持 **数据批量发送** 和 **拉取**；
6.  **零拷贝技术(zero-copy)**：减少 `IO` 操作步骤，提高 **系统吞吐量**；
7.  **数据迁移**、**扩容** 对用户透明；
8.  **无需停机** 即可扩展机器；
9.  **其他特性**：丰富的 **消息拉取模型**、高效 **订阅者水平扩展**、实时的 **消息订阅**、亿级的 **消息堆积能力**、定期删除机制；

#### (b) 部署环境 ####

使用 `Kafka` 需要：

*  `Java JDK`
 *  `Kafka` 安装包

#### (c) 优点 ####

1.  **客户端语言丰富**：支持 `Java`、`.Net`、`PHP`、`Ruby`、`Python`、`Go` 等多种语言；
2.  **高性能**：单机写入 `TPS` 约在 `100` 万条/秒，消息大小 `10` 个字节；
3.  提供 **完全分布式架构**，并有 `replica` 机制，拥有较高的 **可用性** 和 **可靠性**，理论上支持 **消息无限堆积**；
4.  支持批量操作；
5.  **消费者** 采用 `Pull` 方式获取消息。**消息有序**，**通过控制** 能够保证所有消息被消费且仅被消费 **一次**；
6.  有优秀的第三方 `Kafka Web` 管理界面 `Kafka-Manager`；
7.  在 **日志领域** 比较成熟，被多家公司和多个开源项目使用。

#### (d) 缺点 ####

1.  `Kafka` 单机超过 `64` 个 **队列/分区** 时，`Load` 时会发生明显的飙高现象。**队列** 越多，**负载** 越高，发送消息 **响应时间变长**；
2.  使用 **短轮询方式**，**实时性** 取决于 **轮询间隔时间**；
3.  消费失败 **不支持重试**；
4.  支持 **消息顺序**，但是 **一台代理宕机** 后，就会产生 **消息乱序**；
5.  社区更新较慢。

### 7.5. 几种消息队列对比 ###

这里列举了上述四种消息队列的差异对比：

![16479c8ecf7ad3ef_w_793_h_812_f_png_s_61730][]

`Kafka` 在于 **分布式架构**，`RabbitMQ` 基于 `AMQP` **协议** 来实现，`RocketMQ` 的思路来源于 `Kafka`，改成了 **主从结构**，在 **事务性** 和 **可靠性** 方面做了优化。广泛来说，**电商**、**金融** 等对 **事务一致性** 要求很高的，可以考虑 `RabbitMQ` 和 `RocketMQ`，对 **性能要求高** 的可考虑 `Kafka`。

# 小结 #

本文介绍了消息队列的特点，消息队列的 **传递服务模型**，消息的 **传输方式**，消息的 **推拉模式**。然后介绍了 `ActiveMQ`，`RabbitMQ`，`RocketMQ` 和 `Kafka` 几种常见的消息队列，阐述了 **各种消息队列** 的 **主要特点** 和 **优缺点**。通过本文，对于消息队列及相关技术选型，相信你会有了更深入的理解和认识。更多细节和原理性的东西，还需在实践中见真知！

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

欢迎关注技术公众号： 零壹技术栈

![零壹技术栈][16455ec5dcc40392_w_258_h_258_f_jpeg_s_16109]

本帐号将持续分享后端技术干货，包括虚拟机基础，多线程编程，高性能框架，异步、缓存和消息中间件，分布式和微服务，架构学习和进阶等学习资料和文章。

[16479c8ed095ffed_w_989_h_290_f_webp_s_10430]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ed095ffed?w=989&h=290&f=webp&s=10430
[16479c8e7c77109d_w_623_h_242_f_webp_s_6046]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e7c77109d?w=623&h=242&f=webp&s=6046
[16479c8e7c831340_w_653_h_406_f_jpeg_s_51288]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e7c831340?w=653&h=406&f=jpeg&s=51288
[16479c8e7c97b0c3_w_910_h_408_f_jpeg_s_68819]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e7c97b0c3?w=910&h=408&f=jpeg&s=68819
[16479c8e7c89962f_w_832_h_126_f_jpeg_s_14475]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e7c89962f?w=832&h=126&f=jpeg&s=14475
[16479c8e7faf60a5_w_492_h_268_f_jpeg_s_16077]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e7faf60a5?w=492&h=268&f=jpeg&s=16077
[16479c8e800ce905_w_541_h_300_f_jpeg_s_16288]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8e800ce905?w=541&h=300&f=jpeg&s=16288
[16479c8ea267f536_w_595_h_346_f_webp_s_10596]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ea267f536?w=595&h=346&f=webp&s=10596
[16479c8ea3e6231a_w_587_h_401_f_jpeg_s_24739]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ea3e6231a?w=587&h=401&f=jpeg&s=24739
[16479c8ea41e864b_w_648_h_247_f_jpeg_s_18958]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ea41e864b?w=648&h=247&f=jpeg&s=18958
[16479c8ea4b19ea9_w_581_h_574_f_jpeg_s_120422]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ea4b19ea9?w=581&h=574&f=jpeg&s=120422
[16479c8ea7cdc2c0_w_568_h_552_f_png_s_41834]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ea7cdc2c0?w=568&h=552&f=png&s=41834
[16479c8ece3b5d7a_w_635_h_298_f_png_s_36428]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ece3b5d7a?w=635&h=298&f=png&s=36428
[16479c8ec333c809]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ec333c809
[16479c8ec4ba760a_w_708_h_364_f_png_s_55959]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ec4ba760a?w=708&h=364&f=png&s=55959
[16479c8ecf7ad3ef_w_793_h_812_f_png_s_61730]: https://user-gold-cdn.xitu.io/2018/7/8/16479c8ecf7ad3ef?w=793&h=812&f=png&s=61730
[16455ec5dcc40392_w_258_h_258_f_jpeg_s_16109]: https://user-gold-cdn.xitu.io/2018/7/1/16455ec5dcc40392?w=258&h=258&f=jpeg&s=16109