我走过最长的路是你的套路
女：二号男嘉宾，假如我们牵手成功后，你会买名牌包包给我吗？
男：那你会听话吗？
女：会 听话。
男：听话 咱不买！
那么消息队列MQ有什么套路呢？（这个话题转换生硬度连我自己都怕！）使用消息队列场景和好处
使用消息队列会带来什么问题，有什么解决方案
如何使用MQ（以ActiveMQ为例）
1.消息队列的应用场景和好处：
异步-流量削峰
我们先来看下传统的服务器接收处理请求的流程
如上图，在不使用消息队列服务器的时候，用户的请求都直怼数据库，在高并发的情况下数据库压力剧增，不仅使得响应速度变慢，还可能因此而挂掉数据库，导致用户页面直接报错，项目经理找上门，然后*#！%@！#** ......（PS：尽管是某服务挂了，但某宝的用户页面提示信息一定会甩锅给网络不通哦~）
我们再来看加入消息队列服务器之后的接收处理请求的流程会发生什么变化
如上图，在使用消息队列之后，即使在高并发的情况下用户的请求数据发送给消息队列之后立即返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理消息速度比数据库要快很多，因此响应速度（用户体验感）得到大幅改善。
因此我们可以得出消息队列具有很好的流量削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削去高峰期的并发事务。如在某些电商平台的一些秒杀活动中，合理使用消息队列可以抵御活动刚开始大量请求涌入对系统的冲击。
因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票等。
异步-系统解耦
我看也先来看看传统的系统数据传输模式
如上图，主系统和其他系统的耦合性太强，都是直接调用，稍微有一点改动或者新增模块，双方都得改代码，过于麻烦
然后，我们再来看看加入了消息队列之后，系统的结构会发生什么变化
如上图，我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。
消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。 从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。
另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上，等消息真正被消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。
除发布订阅模式之外，消息队列还有其他的传输模式
点对点模型
基础模型中，只有一个发送者、一个接收者和一个分布式队列。