使用消息队列的三个经典场景，异步，削峰，解耦。

异步

就比如下单业务，对于用户而言，流程很短，下完单就完成。但是对于系统后端来说，可能流程，执行链路很长。导致用户就会存在着偏差，明明这么简单一个事情，系统给我反应这么慢。

可以将业务拆分开，将一些没有顺序的流程同时做，也就是异步操作。

解耦

既然是将这些流程同时做，但是不能采用多线程来做。这么多业务要调用这么多接口，全部写在一块出现问题了也不好后期维护，流程中某一点出问题，又会影响到其它独立的点。

用了消息队列，耦合这个问题就迎刃而解了。

下单完成了，就把支付成功的消息告诉别的系统取处理，他们收到了去处理就好了。后面要接入什么系统，只需要监听这个消息即可。

削峰

把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，可能会慢一点，但不至于服务器挂了。

缺点

系统复杂性

本来一个简单系统好好的，现在弄了一个中间件，还要维护它，消息重复消费、消息丢失、消息的顺序消费。

数据一致性

下单服务自己保证自己的逻辑成果处理了，成果发送了消息，但是其它系服务，成不成功得不到保证，所有服务都成功才算一次下单成功。

分布式事务：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。

可用性

中间件毕竟是第三方软件，这个进程有可能挂了的风险。