1.什么时候会用到消息队列？

公司本身业务小，可以做单体的，但是后面业务体量不断扩大，采用微服务的设计思想，分布式的部署方式，所以拆分了很多的服务，随着体量的增加以及业务场景越来越复杂了，很多场景单机的技术栈和中间件以及不够用了，而且对系统的友好性也下降了，最后做了很多技术选型的工作，此时就需要引入消息队列中间件。

2.什么是消息队列？

消息队列：在消息的传输过程中保存消息的容器。

队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

提到消息队列就要想到异步、削峰、解耦 ，就像是提到面向对象会想到封装，继承，多态一样，形成条件反射的那种┗|｀O′|┛ 奥~~

接下来一步步的说做异步，削峰，解耦

3.异步处理

场景：我们在进行淘宝购物的时候，平时的购物流程都是

 中间只会有是支付处理占用时间

当然这样的流程在我们的生活中被应用的已经是少数的了~

我们在进行购物的时候不只是会有下单系统，还会出现积分系统，短信通知系统，优惠券系统等等。。。

这个时候我们就需要用到异步处理，这是为什么呢，请看下图

 假如支付本来100ms可以完成的事，同步处理的话现在这样的流程下来是不是需要500ms

等我用你的软件买下来黄花菜都凉了~

更何况实际的购物流程列举出来的还要多~ o(*￣▽￣*)o

上面的流程其实可以同时做的呀，你支付成功后，我去校验优惠券的同时我可以去增减积分啊，还可以同时发个短信啊。

 这样就可以优化速度啦~

在此我的下意识感觉可以用线程，线程池，阿西吧实际上这种下意识是错误滴

一个订单流程，扣积分，扣优惠券，发短信，扣库存。。。等等这么多业务要调用这么多的接口，每次加一个你要调用一个接口然后还要重新发布系统，写一次两次还好，写多了系统不崩人先崩了，这样的情况不出错还好，出错就是跟bug地老天荒。既然用到了消息队列，就不能跟bug地老天荒，接下来就是

4.应用解耦

你下单了，你就把支付成功的消息告诉别的系统，他们收到了去处理就好了，只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统简单，直接订阅你发送的支付成功消息，你支付成功了我监听就好了。只要自己的流程是成功的就好，管别人的咋样呢bug漫天飞也不影响你嘞~

这是消息队列的缺点一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。

5. 流量削锋

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

• 可以控制活动的人数
• 可以缓解短时间内高流量压垮应用
• 用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面
• 秒杀业务根据消息队列中的请求信息，再做后续处理

6.MQ选型对比文档

 关于选择那个去做消息队列就看具体的需求啦~