【RabbitMQ官网教程系列】一、导读 初识MQ（上）

【RabbitMQ官网教程系列】一、导读 初识MQ（上） 一、系列导读

大家好，本系列文章希望在基于官网教程内容的情况下，通过通俗易懂的语言，来给大家讲解RabbitMQ

写这个系列的初心，是想尝试着带大家一起从官网教程的角度，来学习rabbitmq。相信大家在网上也能找到很多RabbitMQ的视频教程，这些教程的水平在我看来参差不齐，有的甚至让人看完还云里雾里的。于是当时还是rabbitmq初学者的我，怒上官网学习。

当时通过一个月啃官网教程，收货了非常多的知识。不光是rabbitmq的用法，还学习了很多mq的知识、算法、底层逻辑。

这让我非常惊讶。因为以前也去看过rocketmq的官网教程，实话实说，看了一遍下来，很多内容都不知道他在说什么（也可能是我没有get到）。而rabbitmq的官网很不一样，完全可以说是保姆级的教程，通篇看下来，简历里就基本上可以说【掌握rabbitmq】

虽然官网的教程是保姆级的，但我这里还是想尝试着自己写一个系列的教程。原因有两个：一是英文的阅读可能对很多程序员来说比较吃力（毕竟很多同学从离开校园之后就很少接触英文）；二是希望通过更符合咱中国人思维方式的语言，来和大家一起学习rabbitmq。

后续的这一系列的文章里，我在基于官网内容的前提下，尽可能用更通俗易懂的语言，来进行讲解。

我会尽可能的照顾对mq不太了解、以及零基础的同学，让大家看的明白、看的懂。本篇文章的示例代码，是基于java语言。在看本系列文章之前，你只需要掌握java的基本语法即可。

好了，闲话就说到这里，大家有什么疑问或者想一起交流的内容，欢迎大家在评论区留言。

二、初识MQ

因为要照顾0基础的同学，所以我们会花较大的篇幅先来带领大家入个门。这一部分的内容会比较长，如果对MQ很熟悉的同学，直接跳过这部分即可

MQ，英文全程是【Message Queue】，中文翻译过来是【消息队列】。

一件东西的诞生，必然是要解决某些问题的。那MQ是用来解决什么问题的，他的应用场景又是什么呢？

在这里，我想通过告诉收费站的例子，来讲解MQ以及它的相关作用。

我们开车上高速时，会通过收费站。下高速时，也会经过收费站。如果我们办理了ETC，那就非常方便：只需要走ETC专用的进出口，就可以实现自动扣费功能，无需收费站人员手动收费。

这里，我们就以下高速出ETC口举例。

我们先回顾下这个例子的场景：车辆到ETC出口后，摄像头成功自动识别到我们的车牌号，然后闸机栏杆抬起，车辆出高速。

如果让我们来设计这个程序，我们是不是很容易想到以下的这个架构

我们来看一下这4者之间的信息流转：首先【车】开到ETC出口，被出口的【摄像头】识别出车牌号码，然后摄像头将车牌号码信息传递给本地的【收费站ETC程序】，然后再将消息转发给【后台ETC程序】。

这里我们说明一下，为什么要在【摄像头】和【后台ETC程序】之间，加一个【收费站ETC程序】。

这个【收费站ETC程序】，主要是对【摄像头】传过来的信息做一些加工，比如添加一些发送时间、发送的收费站名（如广东省广州市XX收费站XX出口），然后再传到【后台ETC程序】。

这里提前说明一下，我们举这个收费站的例子，是为了更方便的让大家理解MQ，收费站本身的程序设计，肯定会更复杂。

好了，我们来看下信息在各个组件之间是怎么流动的。首先【摄像头】识别到车辆的车牌号后，将车牌号发送给【收费站ETC程序】。注意，这个过程是在本地收费站进行的，并不涉及将信息传递给远端的【后台ETC程序】。如下图

接下来【收费站ETC程序】将信息进行加工，这里我们假设增加了收费站名信息。然后发送给【后台ETC程序】。

接下来等【后台ETC程序】信息处理完之后，再返回信息给【收费站ETC程序】。【收费站ETC程序】再控制闸机栏杆抬起，如下图

好了，到目前为止，我们规划了一个系统架构图，他看上去能满足我们的需求。我们先将它补全：因为有很多的收费站，所以我们将图补全如下：

好了，这个系统貌似能实现我们的相关功能了。但我们回想下实际的情况：我们出收费站，是不是要扣除绑定的yhk里对应的金额呢？所以我们上图还少了一个组件：银行系统。

我们来梳理下整个的扣钱流程：【摄像头】识别到车牌号，发送给【收费站ETC程序】；【收费站ETC程序】经过加工处理之后，将信息发送给【后台ETC程序】。

然后【后台ETC程序】将扣费信息发送给【银行后台程序】，【银行后台程序】扣完钱之后，返回消息给【后台ETC程序】，【后台ETC程序】再发送消息给【收费站ETC程序】，控制栏杆抬起。如下图

好了，到目前为止，我们画出了ETC整体的信息流程。这里我们先提出一个问题：
如果银行后台程序宕机或者维护怎么办？

从上图可以看出，如果想要这一整套机制能24小时运行，需要【银行后台程序】时刻稳定可用才行。但是，假设我们作为ETC系统的运维人员，我们最多最多只能保证自己的这一整套东西24小时可用，但是银行的系统是否24小时可用，我们不能保证（比如有时候银行的系统会暂停服务）

当【银行后台程序】不可用之后，按照上面的信息流来看，是不是整个ETC系统都不可用了呢？答案是肯定的。

那用户能接受这种结果么？当然不行，毕竟ETC是需要支持24小时工作的。

那我们应该怎么解决这个问题呢？采用MQ！

在下一讲中，我们将阐述MQ是如何来规避我们上面提到的这个问题的，然后大家就可以明白，MQ的功用到底是什么了