Table of Contents:

没有最好的技术，只有最适合的技术，不要为了用而用。

直观感受

消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。
举个例子：假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作：
* 校验用户名等信息，如果没问题会在数据库中添加一个用户记录
* 如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
* 分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
* 发送给用户一个包含操作指南的系统通知
* 等等……

在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。

使用的场景

异步

我们之前的场景里面有很多步骤都是在一个流程里面需要做完的，就比如说我的下单系统吧，本来我们业务简单，下单了付了钱就好了，流程就走完了。
但是后面来了个产品经理，搞了个优惠券系统，OK问题不大，流程里面多100ms去扣减优惠券。
后来产品经理灵光一闪说我们可以搞个积分系统啊，也行吧，流程里面多了200ms去增减积分。
再后来后来隔壁的产品老王说：下单成功后我们要给用户发短信，也将就吧，100ms去发个短信。
再后来。。。

嗯不错，链路长了就慢了，那你怎么解决的？
那链路长了就慢了，但是我们发现上面的流程其实可以同时做的呀，你支付成功后，我去校验优惠券的同时我可以去增减积分啊，还可以同时发个短信啊。
那正常的流程我们是没办法实现的呀，怎么办，异步。不仅是可以线程级别的异步，还可以是机器级别的异步。

解耦（发布订阅模式）

你下单了，你就把你支付成功的消息告诉别的系统，他们收到了去处理就好了，你只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统简单，直接订阅你发送的支付成功消息，你支付成功了我监听就好了。

那你的流程走完了，你不用管别人是否成功么？比如你下单了积分没加，优惠券没扣怎么办？ 问题是个好问题，但是没必要考虑，业务系统本身就是自己的开发人员维护的，你积分扣失败关我下单的什么事情？你管好自己下单系统的就好了。Tip：话是这么说，但是这其实是用了消息队列的一个缺点，涉及到分布式事务的知识点，我下面会提到。

削峰

拿秒杀来说，你平时流量很低，但是你要做秒杀活动00 ：00的时候流量疯狂怼进来，你的服务器，Redis，MySQL各自的承受能力都不一样，你直接全部流量照单全收肯定有问题啊，直接就打挂了。
简单，把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，你能处理5000QPS你就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，你的服务也就没压力了。

缺点

系统复杂性

本来蛮简单的一个系统，我代码随便写都没事，现在你凭空接入一个中间件在那，我是不是要考虑去维护他，而且使用的过程中是不是要考虑各种问题，比如消息重复消费、消息丢失、消息的顺序消费等等，反正用了之后就是贼烦。

数据一致性

这个其实是分布式服务本身就存在的一个问题，不仅仅是消息队列的问题，但是放在这里说是因为用了消息队列这个问题会暴露得比较严重一点。就像我开头说的，你下单的服务自己保证自己的逻辑成功处理了，你成功发了消息，但是优惠券系统，积分系统等等这么多系统，他们成功还是失败你就不管了？
所有的服务都成功才能算这一次下单是成功的，那怎么才能保证数据一致性呢？
分布式事务：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。

可用性

你搞个系统本身没啥问题，你现在突然接入一个中间件在那放着，万一挂了怎么办？我下个单MQ挂了，优惠券不扣了，积分不减了，这不是杀一个程序员能搞定的吧，感觉得杀一片。至于怎么保证高可用，还是那句话也不在这里展开讨论了，我后面一样会写，像写Redis那样写出来的。