MQ（Message Queue）：消息队列。通过典型的生产者和消费者模型，生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，轻松的实现系统间解耦。别名为消息中间件，通过利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
MQ的作用：
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段。当今市面上由很多主流的消息中间件，如ActiveMQ、RabbitMQ、Kafka、RocketMQ等。
异步处理：
场景说明：用户注册后，需要发注册邮件和注册短信，传统的做法有两种：1）串行的方式；2）并行的方式
1）串行的方式
将注册信息写入数据库后，发送注册邮件，再发送注册短信。以上三个任务完成后才返回给客户端。这有一个问题是，邮件，短信并不是必须的，它只是一个通知，而这种做法让客户端等待没有必要等待的东西。
2）并行方式
将注册信息写入数据库后，发送邮件的同时，发送短信。以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间。
假设三个业务节点分别使用50ms，串行方式使用时间150ms，并行方式使用时间100ms。虽然并行方式已经提高处理时间。但是，邮件和短信对正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功，因此写入数据库后就返回。
3）消息队列
引入消息队列后，把发送邮件，短信不是必需的业务逻辑异步处理。
由此可以看出，引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间（可以忽略不计），明显快于串行方式处理和并行方式处理。
应用解耦
场景：双11是购物节，用户下单后，订单系统需要通知库存系统，传统的做法就是订单系统调用库存系统的接口。
这样做法有一个缺点：订单系统和库存系统高耦合，当库存系统出现故障时，订单系统就会失败。
引入消息队列
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
库存系统：订阅下单的消息，获取下单消息，进行库操作。就算库存系统出现故障，消息队列也能保证消息的可靠投递，不会导致消息丢失。
流量削峰
流量削峰一般在秒杀活动中应用广泛
场景：秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，一般在应用端加入消息队列。
作用：
可以控制活动人数，超过一定阀值的订单直接丢弃。
可以缓解短时间的高流量压垮应用（应用程序按自己的最大处理能力获取订单）
用户的请求服务器，服务器收到后，首先写入消息队列，加入消息队列长度，超过最大值，则直接抛弃用户请求或跳转到错误页面。秒杀业务根据消息队列中的请求消息，再做后续处理。
几类MQ比较
ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。它是完全支持JMS规范的消息中间件。丰富的API，多种集群架构模式让其在业界成为老牌的消息中间件，在中小企业颇受欢迎。
Kafaka 是LindedIn开源的分布式-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志的收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复，丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
RocketMQ 是阿里开源的消息中间件，它是纯java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于卡夫卡，但不是kafka的一个copy，它对消息的可靠传输及事务做了优化，目前在阿里集团被广泛用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
RabbitMQ 是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅），可靠性、安全。AMQP协议更多用在企业系统内对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求其次。
RabbitMQ比kafka可靠，Kafka更适合IO高吞吐量的处理，一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢失数据）要求稍低的场景使用，比如ELK日志处理。
