为什么要用消息队列
代码解耦， 提高系统稳定性
比如说我们订单系统它会不停的去产生订单对吧？但是其实想要订单数据的系统是非常多的，比如说数据统计团队、运营团队等等，他们都想要相关的数据，假设我们不使用这个消息队列，有可能别的系统会要求我们在产生数据之后把这个数据推送给他们一份，假设只有一个系统需要我们的数据，这还好办，我们只需要在产生订单消息之后调一下对方的接口，把这个数据传给他就可以了。但是实际情况可不是这样的，需要订单信息的模块会越来越多，我们总不可能说有一个模块需要我们的信息，我们就改一次代码对吧？
所以在这种情况下就非常适合使用消息队列，我们只需要把订单数据发给消息队列，那么谁需要订单消息，谁就去找消息队列拿，这样就可以了。也不需要我们把数据写到对方的数据库，也没有形成一个强依赖，即便是对方的营销系统出了问题，那么我们订单系统呢也不会受到任何的影响。所以这个就是使用消息队列的第一个好处，就是代码解耦，并且提高了系统的稳定性
可以应对流量高峰，降低流量的冲击
这个是什么意思？尤其体现在秒杀这种场景下。在秒杀的时候，我们为了防止海量用户直接把我们服务器冲垮，我们可以使用消息队列对方的请求进来，先到队列中去排队，这样一来我们在处理的时候就可以从容不迫了，我们如果能处理得过来，那么就把这个消息队列消费的速度快一些，假设处理不过来，消费的速度就慢一些，但至少可以保证我们整体系统还是相对稳定的。
异步的执行，提高系统的响应速度
我们来举一个例子，平时我们去一些网红的餐馆去吃饭对吧？这个时候它有两种排队方式，第一种就是你取号有取号机，然后你就走了，然后在取号机上它会有一个二维码，你扫了之后快到你的时候，他会给你推动一个消息，这明显就是非常高效的一种手段，因为排队的时候你不需要人一直待在那里，也不需要在那边傻等你可以去干别的，可以去逛街对吧？
这就好比是在我们的系统中使用了消息队列，比如说我们想去吃饭想去排队，实际上就意味着往消息队列中发送了一个消息，但是餐厅它处理消息的速度是有限的，因为他座位有限，所以他要慢慢处理，然后等到他处理到我们这个消息的时候，他会来通知我们，这个就是消息堆列的好处。
假设我们不使用消息队列，我们就相当于要人肉在那边排队，像以前还没有这些交换系统的时候，确实都是这样的，有一些店比较火，你就必须人肉在那边排队，你必须在那边等着，也不能走开的话，队伍就相当于你白排了。
所以在你等待的期间你什么都干不了，这个就好比是我们没有消息队列，如果没有消息队列，大家的执行都是同步的，同步的意思就是你调用之后你要一直在这边等待，直到这个消息返回，这样的话整个系统的反应速度就非常慢，效率也降低了很多。所以这个就是使用消息队列的第三点好处，可以提高系统的响应速度。
总结
-
- 系统解耦（最重要）
如果系统接收方比较少的时候，可以直接调用接口处理。一旦业务越来越复杂，接收方越来越多，就需要调用非常多的接口，处理时间大大延长了。其次不易维护。通过mq解耦后，只需要把消息发给mq中间件，谁想收到消息就可以自己处理，比如说订阅我们的消息，我们就不需要理会后面的事情。
-
- 异步调用：
比如a调用b，c，d，因为每一个步骤需要时间，整个就比较耗时。这个时候可以使用异步
异步：先告诉你要做这件事情，不等你做完可以直接返回
同步：告诉你要做，然后你现在就做，做完后告诉我做完了，我再去返回
-
- 流量削峰
有个时候流量会突然上升，出现流量高峰（比如中午点外卖的时候是饿了么的流量高峰），可能一天就只有半小时是流量高峰，剩下都是低谷，不能为了这半小时高峰去多准备服务器，这是资源浪费。有了mq以后，mq可以先把请求存放到队列里面，
然后再以我们能接收的速度发给我们，这样我们收到请求的速度不会特别快，我们不会被打垮。其次又不需要增加机器，我们只需要用消息队列对高流量做一个缓冲存储，然后把压力逐步化解。当然高峰期时队列会挤压很多消息，但是随着时间推移，流量高峰会慢慢被我们处理，最终处理完毕，所以很多情况下都适合使用这种方案。