1. MQ、队列、RabbitMQ使用场景

MQ

全称 Message Queue，被称为消息队列

回顾队列

队列，类似于一种 List 结构，专门来存储数据的队列

如果要往队列中存数据的话

可以从队头中存，1先进，存到队列中就是这样：3 -> 2 -> 1，从队尾取的时候，1先出，结果就是这样：1 -> 2 -> 3，这是很典型的先进先出队列

如果存的方式与上面一样：3 -> 2 -> 1，而取的时候从队头取，3先出，结果就变成了这样：3 -> 2 -> 1，这就是先进后出

如果队头、队尾都可以放数据，这样的队列被称为双端队列

Java 中也提供 Queue 的相关操作，但是 Java 里面的 API 都是基于内存级别的，而我们的微服务使用它的 API 来保存数据，那最多只能在它的机器里面使用

分布式系统中，我们需要消息中间件 ，是安装在服务器里的，我们的消息全部保存到这个服务器里面，所有微服务都可以通过这个服务器取消息，而 RabbitMQ 就是我们要使用的消息中间件

RabbitMQ使用场景

1.异步处理

假设我们的一个普通业务，以用户注册为例，用户通过浏览器提交了账号、密码等注册信息，注册信息可能分为以下这三步

这是一种同步模式，用户在每一个步骤都会花费 50ms 的时间，加起来就是 150ms 的时间， 我们发现这是没有必要的

尤其是第2步跟第3步，如果我们使用下面这种模式，可以给它弄一个异步

用户将注册信息写入到数据库之后，我们创建两个异步任务，一个发送注册邮件，一个发送注册短信，当然我们需要最终的完整返回，但是我们只需要等待时间最长的一个返回，就可以获取到两个结果

这样，我们就将时间缩短到了 100ms ，看起来时间更快了，但是实际上，我们连异步都不需要

因为，我们发现注册邮件、注册短信，这两个任务，让它在后台慢慢发就行，成功或是失败，我们无需知道，只要它做了这个事就行，而且我们经常会有收不到短信、收不到邮件的情况，所以，遇到这种情况，我们还可以使用下面这种方式

我们如果将注册信息写入数据库成功了，接下来，我们将注册成功的消息写入消息队列，保存在消息中间件这个服务器中，假设：保存了一个1号用户注册成功的消息，至此，我们就直接给用户返回

因为给消息中间件写消息这个耗时是非常短的，数据库插入数据库可能很慢，需要 50ms ，而写消息，类似于直接操作 redis 一样，可能只花费 5ms，很快，那么用户收到这个响应只需要 55ms，但是用户能不能收到邮件、短信呢？

也可以，我们的消息既然存到了消息队列里面，别的服务就可以从消息队列里面拿到这个消息，假设：这个服务拿到1号用户注册成功的消息了，那么它就在后台该发邮件发邮件，该发短信发短信，我们不关心它什么时候发短信、发邮件，只要它干了这个事就行，但是用户会一起响应成功。

总结

这就是异步处理，使用起来比异步任务更快，异步任务我们还必须等待消息返回，而这个异步处理，只需要给消息中间件的服务器发一个消息，让它在后台慢慢处理就行。

2.应用解耦

我们以下订单为例：比如，我们下了一个订单，我们下完订单之后，需要做出库操作，像我们以前做的，一般是使用下面这种方式

假设订单系统有3个参数，库存系统有5个参数，直接调用就可以，如果这个库存系统不升级，API 也不变，一直是这几个参数还好，

假设我们库存系统经常会升级， 减库存的接口经常发生变化，这样我们以前的这种调用方式，一旦库存系统升级了，则订单系统必须修改它的源代码，重新部署，这样就感觉会非常麻烦，所以我们可以引入消息队列，

订单系统只要下好订单，我们给消息队列里面写上一个消息，说我们哪个用户下了哪个订单购买了哪个商品，把这个消息保存到队列里面，我们不关心库存系统的接口是什么样，不管它要几个参数，我们只需要把我们的消息写进去，接下来库存系统要实时订阅我们队列里面的内容，只要有内容，库存系统就会收到我们订单系统写的消息，然后它自己分析消息，然后对库存进行修改

总结

此时，我们发现，订单系统执行完任务之后，我们无需关心库存系统要调用什么接口，我们只需要写消息即可，所以我们就实现了应用解耦

以后，无论什么系统，想要知道我们订单成功之后要做什么，只需要订阅消息队列中订单成功的消息，

而订单系统不需要关心别的系统接口设计成什么样子，因为订单系统根本就不会调用它们

3.流量控制（流量削峰）

针对一些秒杀业务来说，瞬间流量会非常大，比如：瞬间百万个请求都要进来秒杀一个商品，这个商品要真正去执行业务，就算我们前端服务器可以接受百万请求，我们要执行业务代码，因为我们秒杀完之后，要下订单，整个流程会非常慢， 后台会一直阻塞，可能就会导致资源耗尽，最终导致宕机

此时，我们可以这样做，我们让大并发的请求全部进来，进来以后，先将它们存储到消息队列里面，存到消息队列以后，我们就可以不用管这个请求该怎么做了，直接给它响应：秒杀成功了或者其他

然后，消息队列中，后台真正的业务处理要下订单、减库存等等这些业务处理，我们不着急立即调用，只要存到消息队列里面，这些业务去订阅消息队列里面进来的这些秒杀请求，接下来，挨个处理：下订单…，即使后台每秒只能处理1个，那100W请求，也就花费100W秒，但永远都不会导致机器的资源耗尽，导致宕机所以我们可以达到前端的流量控制。

总结

我们把所有的流量存到队列里面，后台根据它的能力，去来进行消费处理，不会导致机器宕机，这就是流量控制，也被称为流量削峰

将峰值削下来，全部存到队列里面