1.什么是消息队列？
消息队列就是一个用来存储消息的队列嘛。队列（queue）。队列可以说是一个数据结构，可以存储数据，我们从右侧（队尾）插入元素（入队），从队头获取元素（出队）。
消息队列就是我们常说的MQ，英文叫Message Queue，是作为一个单独的中间件产品存在的，独立部署。其实感觉在某些方面有一点点类似于缓存。
2.为什么要使用消息队列？
消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。目前使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ。
另外，我们知道队列 Queue 是一种先进先出的数据结构，所以消费消息时也是按照顺序来消费的。比如生产者发送消息1,2,3...对于消费者就会按照1,2,3...的顺序来消费。但是偶尔也会出现消息被消费的顺序不对的情况，比如某个消息消费失败又或者一个 queue 多个consumer 也会导致消息被消费的顺序不对，我们一定要保证消息被消费的顺序正确。除了上面说的消息消费顺序的问题，使用消息队列，我们还要考虑如何保证消息不被重复消费？如何保证消息的可靠性传输（如何处理消息丢失的问题）？......等等问题。所以说使用消息队列也不是十全十美的，使用它也会让系统可用性降低、复杂度提高，另外需要我们保障一致性等问题。
2.1解耦
解耦，就是降低耦合度，那MQ又是如何解耦的呢？假如系统A是一个关键性的系统，产生数据后需要通知到系统B和系统C做响应的反应，三个系统都写好了，稳定运行；某一天，系统D也需要在系统A产生数据后作出反应，那就得系统A改代码，去调系统D的接口，好，改完了，上线了。假设过了某段时间，系统C因为某些原因，不需要作出反应了，不要系统A调它接口了，就让系统A把调接口的代码删了，系统A的负责人可定会很烦，改来改去，不停的改，不同的测，还得看会不会影响系统B，系统D。没办法，这种架构下，就是这样麻烦。更不要说什么时候出点异常情况，麻烦滴很。
但是有了消息队列就不一样了系统A产生数据之后，将该数据写到MQ中，系统A就不管了，不用关心谁消费，谁不消费，即使是再来一个系统E，或者是系统D不需要数据了，系统A也不需要做任何改变，而系统B、C、D是否消费成功，也不用系统A去关心，通过这样一种机制，系统A和其他各系统之间的强耦合是不是一下子就解除了，系统A是不是一下子清爽了很多？就像流水线一样，一个人干不过来了，再加一个人帮他分担你一部分工作就会明确很多，避免手忙脚乱。
2.2削峰
削峰是什么意思？大家都知道对于大型互联网公司，典型的就是电商，时不时的搞一些大促，流量会高于平时几十倍几百倍...例如，平时下单也就每秒一二十单，对于现有的架构来说完全不是事儿，那大促的时候呢？每秒就有可能举个例子是5000单，如果说下单要实时操作数据库，假设数据库最大承受一秒2000，那大促的时候一秒5000的话数据库肯定会被打死的，数据库一挂导致系统直接不可用，那是多么严重的事情。
所以在这种场景下使用MQ完美的解决了这个问题，下游系统下单时只需要往MQ里发消息，我的订单系统可以设定消费的频率，比如每秒我就消费2000个消息（在数据库的可承受范围），不管你下游系统每秒下多少单，我都保持这个速率，既不会影响我订单系统的数据库，也不影响你下游系统的下单操作，很好的保护了系统，也提高了下单的吞吐量。
我们都知道，大促也就几分钟的事，往多了说是几个小时吧，咱就说4个小时吧，每秒5000，4小时7200W单往MQ里写，订单系统每秒消费2000单，大促过后，MQ里会积压4320W个消息，剩下的就慢慢消费呗。当然了，大促的时候肯定会临时申请加机器的，每秒消费不止2000。
这就是削峰，将某一段时间的超高流量分摊到更长的一段时间内去消化，避免了流量洪峰击垮系统。就是流水线上的新工人会控制流量，不会让大部分产品流入下一个岗位。
2.3异步
没有使用MQ时，系统A要调系统B、C、D的接口，系统A的用户做完这个操作就需要等待：200ms+300ms+300ms+300ms=1100ms=1.1s假设使用了MQ呢？系统A就只需要把产生的数据放到MQ里就行了，就可以立马返回用户响应。这样系统A的用户做完这个操作就只需要等待200ms+50ms=250ms，给用户的感觉就是一瞬间的事儿，点一下就好了，用户体验提升了很多。系统A把数据写到MQ里，系统B、C、D就自己去拿，慢慢消费就行了。一般就是一些时效性要求不高的操作，比如下单成功系统A调系统B发下单成功的短信，短信晚几秒发都是OK的。
非常简单，就是说A工人是检测产品是否合格的检测完后需要送到指定的地方，但是这样会很耗时，这时B工人帮他去送，A工人就会快很多。
3.缺点
3.1、增加了系统的复杂性。
3.2、降低了系统的可用性。
