消息队列也算是当前面试中必问的一个知识点了。而且，如果你说不会，好像别人就抓住了你的短板一样。
现在到哪都一堆人，行情和当年差的太多了。今天，为了不适尴尬，能和面试官聊的更嗨，我给你说说，消息队列的 3 大使用场景。
当然，消息队列绝对不限于这 3 个场景。我概括的还是比较笼统的，抓住主要的场景，就是抓住了面试的机会。
1、支持异步处理的服务。
这个是消息队列使用的一大场景。比如，在电商项目中，我们的下单，出库，扣减库存，短信通知，报表统计等都是可以支持和使用消息队列的。
在这些场景中，有了消息队列后，对用户的体验也很高。比如，如果不使用消息队列，当我们支付成功后，需要进行出库，就需要在支付成功后，直接发起出库请求到网关，或者通过定时任务去通知出库。而有了，消息队列后，就可以支持异步处理了。
再比如，我们有些订单是，下单减库存，有些是支付减库存。有了消息队列，对于订单服务和库存服务就能更好的进行异步处理了。而且，伴随着一个订单的状态的变化，可以针对不同状态的订单形成很多的订阅。
可能还有人问，只异步处理，也显示不出来消息队列的优势吧。那我们来看看第二大使用场景。
2、限流，流量或流速控制。
和现实中的排队一样，消息队列还能控制着流速。类似的就是，当生产者和消费者不能很快进行消费的时候，就可以利用消息队列进行堆积。
再比如，在秒杀场景中，1000 个人，可能会有 1000 个设计。但是，利用消息队列来限制并发也是一种不错的办法。
3、降低代码的耦合度
说一千道一万，我也可以不使用消息队列来实现业务功能。但是，能否在实现功能的同时做到解耦。这也是架构设计中的一个关键，耦合度越高，越难扩展。
而且，解耦之后，针对不同的主题，你随时可以去形成订阅。尤其是对于快速发展的系统，变更是常有的事，当我们能做到解耦后，上游系统和下游系统之间的变更，依程度就不是那么高了。架构的平衡艺术就发挥的淋淋尽致。
以上 3 点，对消息队列的使用场景也没有完全总结全，但是我认为这是特别重要的 3 点。如果你也有想法和使用场景，请留言说出来，一起精进！