消息队列是很早以前就有的一种中间件。由于系统之间需要通讯，所以消息队列就产生了。消息队列的使用场景主要有以下几个场景。
1.异步处理
比如我们要设计一个秒杀系统的解决方案（当然秒杀系统有很多解决方案，这里只是举一个简单的例子）。秒杀系统主要就是解决有限的服务器资源完成瞬时尽可能多的海量请求。但是一个秒杀请求又有很多问题需要解决，比如：
1）风险控制
2）库存锁定
3）生成订单
4）短信通知
5）其他
如果按照传统方式，我们的秒杀系统需要依次处理以上问题，最后将结果返回前端。但是我们知道，只有风险控制与库存锁定是秒杀系统的关键服务，对于像生成订单和短信通知等并不是一定要在秒杀请求中立刻处理的服务。所以，秒杀请求我们只需要处理前两个服务，然后就可以直接返回秒杀请求结果。对于后续的服务，我们可以通过消息系统来完成。如下图：
传统处理方式
消息系统
通过MQ系统，我们可以将一个秒杀的请求步骤减少，非主要服务通过异步方式处理。较少一个请求的处理时间，从而提高服务器的QPS。
2.流量控制
我们仍然以秒杀系统为例，虽然上面的方式已经减少了服务器压力，提高的QPS。但是在面对更大量的请求的时候，服务器总有处理不过来的时候。毕竟服务器资源是有限的，那么为了保证服务器不被系统压垮，我们需要提高服务器的健壮性，这里我们通过MQ系统来隔离后端的服务请求，所有的请求都先提交到MQ系统中，而后端服务器则只需要根据自己的实际处理能力来处理请求即可。对于超时的请求，则直接丢弃。前端controller层可以直接秒杀请求失败。
这样做的好处是：提高了系统的健壮性，在高并发情况下，请求不会直接冲死后端服务。运维可以通过请求数据水平扩容服务器实例，不需要修改任何代码。
这样做的坏处是：服务链路过长，系统复杂度增加。
如果我们可以预估自己服务器处理容量，我们可以采用另一个令牌桶的方式处理。大概方法就是我们做一个定时令牌器，将令牌定时放入一个桶中，如果满桶了，则丢弃令牌，否则就将令牌存入。在一个请求过来的时候，我们的controller取令牌，如果取到了，就处理请求，如果取不到，直接返回失败。示意图如下：
3.服务解耦
服务解耦最典型的例子就是订单的处理。我们知道，一个订单新建成功以后，我们往往需要调用比如：发起支付，短信通知服务等等。但是随着业务的发展，业务逻辑原来越复杂，我们可能又新增了诸如大数据统计模块等服务。传统的方式就是我们做订单的同学需要重新修改逻辑，来对应新增的服务。但是通过MQ系统的订阅方式，我们只需要将订单消息发布出去，所有需要消费订单处理的服务订阅订单消息服务就可以了。这样新增的服务不再需要修改订单的逻辑，达到解耦的目的。
总结
通过上面的说明，我们发现MQ系统在分布式系统中的应用还是非常广泛的。所以，如何在分布式框架中用好一个MQ系统，也是我们所必须了解熟悉的。好的MQ使用可以达到事半功倍的效果。对于MQ系统的使用，我也仅仅是在工作中使用过一点点的功能。后续我会将我在使用MQ系统中遇到的一些问题一一说明一下，希望能对看到的人有所帮助。