以下是本消息队列系列文章的传送门：

• （一）消息队列应用场景
• （二）消息队列技术选型
• （三）kafka

1. 什么是消息队列

队列相信大家应该都不陌生，它是一种先进先出的数据结构，基本结构如下图。

队列

在java中已经实现了各种各样的队列了，那为什么还需要消息队列MQ（Message Queue）这种中间件呢？我们可以先尝试思考一下消息队列存在的意义，它能满足我们项目中的什么需求，下面我会继续补充。

消息队列可以简单理解为，我们把想要传输的数据放到队列中（其结构与普通队列是一样的）

消息队列

我们将把数据放入到队列的那一方叫做生产者；将从消息队列中取数据的一方叫做消费者。

2. 为什么要使用消息队列

以下我将通过几个简单的场景来简单说明我们为什么使用消息队列。

2.1 解耦

假设我们现在有一个环境数据生成系统A，系统A通过调用系统B和系统C的接口来向系统B、C来发送数据，场景一图如下：

场景1

即系统A在有新的环境数据生成时，会通过调用B、C系统的接口来将生成的数据发送给B、C。写成伪代码如下所示（此处不考虑用观察者模式实现解耦并实时通知观察者的情况）：

public class SystemA {
 // 系统B和系统C的依赖
 SystemB systemB = new SystemB();
 SystemC systemC = new SystemC();
 // 系统A独有的数据
 private String environmentData= "data";
 public void doSomething() {
 // 通过调用接口发送数据
 systemB.SystemBNeed2do(environmentData);
 systemC.SystemCNeed2do(environmentData);
 }
}

这种情况下，会有以下问题：

• 如果某一天系统B不需要这些数据了，让系统A的负责人将发送数据给他们的那一部分代码给改了，即注释掉systemB.SystemBNeed2do(environmentData);；
• 有新的系统D需要这些数据了，需要增加调用D系统接口来发送数据的代码；
• 同时，系统A还需要考虑如果其余系统B、C、D的系统如果挂了怎么办，要不要重发。

从上面的场景可以发现，系统A与其他三个系统高度耦合了。我们试想如下场景二，系统A将最新的环境数据信息放到MQ中，哪个系统需要就可以订阅这个消息消费。如果某个系统不需要这些数据了，就取消对MQ消息的消费即可。这种场景下，A系统完全不需要去考虑将数据发送给谁，也不需要去维护之前发送数据的代码，不需要考虑其他系统是否调用成功、失败超时等情况。

场景2

小结：
通过这种模式消息发布与订阅的模式，使得系统A与其他系统解耦。

2.2 异步

其实我仔细斟酌了一下异步与解耦的场景，发现其实异步与解耦是有一定关系的，我们使用同样的场景，只是我们考虑的面不同，场景三如下图所示。但我们现在考虑的面是时间效率。

场景3

假设系统A产生环境数据需要100ms，调用系统B、C、D的接口分别需要300ms、300ms、300ms，那么在类似场景一的设计方式时，这次请求所需要耗费的时间为100+300+300+300 = 1000ms = 1s。请求会随着需要环境数据的系统越来越多而使得请求响应越来越慢，这是用户不能忍受的，即类似我们去请求一个系统服务，我们主要想要的服务只是系统A生成的环境数据服务，而系统A这个时候却因为其它系统调用而使得这个服务请求响应过慢。

而如果是类似于如下场景时，我们的响应时间仅仅是产生消息的时间100ms。

场景4

小结：

• 同步场景下，整个请求需要耗时1s；
• 异步场景下，请求只需要100ms。

2.3 削峰/限流

我们接着考虑如下场景，假设我们的系统A有个促销功能，大促销期间并发量较大，我们假设每秒可能有5k个请求。如下图。

场景5

一般的MySQL，每秒能处理2k个请求就差不多了，如果每秒5k个请求同时处理的话，可能会导致MySQL不可用，导致整个系统崩溃，用户也就没法使用MySQL了。但一过了促销期，每秒请求只有百来个，这个时候对系统几乎没有任何压力。

如果使用MQ，每秒5k个请求写入MQ，A系统可以根据自身的处理能力来决定每秒拉取的请求数。这样下来，在高峰期时系统A也不会挂掉。

场景6

这个短暂的高峰期积压是完全OK的。（消息队列是支持吞高吐量的，为此不用担心这个量的问题，同样，我们可以暂不考虑MQ挂掉的情况）。
系统A按照它能处理的速率来处理请求。

小结：
通过将请求放在支持高吞吐量的MQ中来到达削峰/限流的效果。

2.4 其它应用场景

• 日志处理：将大量日志存储到消息队列中（一般采用分布式消息队列kafka），解决大量日志传输的问题。其中，消息队列负责日志数据的接收，存储和转发；
• 消息通讯：点对点通讯或聊天室通讯。

3. 使用消息队列会有什么优缺点

优点其实就是上文中谈到的，在特殊场景下的应用好处，解耦、异步与削峰等。

系统可用性：
系统因为依赖与MQ消息队列这个服务，若这个服务崩溃了，那么我们的整个系统将不可用。为此往往我们都是通过集群/分布式部署来实现MQ高可用的。

系统复杂度：
我们将数据写到消息队列上，就有可能会存在数据丢失的情况。以及我们如何保证消息没有被重复消费等问题。

一致性问题：
A系统将请求写入到消息队列后就返回请求成功了，假设在多机部署的时候，系统B、C写库成功，假设D写入失败了，这种情况下就会产生数据不一致的问题。

4. 后语

总的来说，虽然引入消息队列有很多好处，但是也得针对它的缺点来引入其它技术方案和架构来规避这些问题，所以我们应该按照我们的实际需求与场景，来选择我们的技术方案。

本人水平有限，难免有错误或遗漏之处，望大家指正和谅解，欢迎评论留言。