MQ概述
MQ是Message Queue的简称，意为消息队列，从字面意思上可以理解MQ的是一个存放消息的容器，并且它的数据结构为队列（FIFO先进先出）。MQ一般应用于应用解耦，异步处理提速，流量削峰，实现高性能，高可用，可伸缩和最终一致性架构。
在MQ中一般存在三种角色Broker、生产者、消费者，在不同的MQ产品中，也会存在不同的其他角色，这里只简单介绍一下主要的三种角色的作用：Broker也就是MQ服务，用于将生产者发送过来的消息按照类型分类存放在不同的队列中；生产者（自己实现）用于将数据发送到Broker；消费者（自己实现）用于从消息队列中获取数据进行消费。
MQ的优势
1、应用解耦：解耦各个应用，提高系统的扩展性、容错性和可维护性；比如在电商系统中订单系统需要调用库存系统、支付系统、物流系统进行业务操作，假如库存系统宕机，那么整个系统将不可用。使用了MQ之后，订单系统与库存系统的耦合度降低，库存系统挂掉不会影响订单主业务流程。
原始架构
MQ架构
2、异步提速：提高接口响应速度和系统吞吐量，提升用户体验；在分布式架构中，我们经常使用http、rpc等方式进行服务间的接口调用，那么假如订单系统调用库存系统修改库存需要300ms，成功修改库存后再调用支付系统进行支付需要300ms，最后支付完成调用物流系统进行发货需要300ms，再加上订单入库需要50ms，那么创建订单的响应时间大概在950ms左右。假如使用MQ，订单系统只需要将数据发送给MQ，由库存系统、支付系统、物流系统去消费即可，由于MQ的性能很高，速度很快，订单系统发送三条数据只需要30ms，再加上订单入库需要50ms，那么创建订单的响应时间则缩短为80ms左右，响应速度大大提高。
原始架构
MQ架构
3、削峰填谷：可以很好的应对突发的大量请求，提高系统稳定性；举个例子，现实中经常使用水库水坝治理比较大的河流，当夏季洪水来临时，水库可以很好的容纳洪水，通过控制水坝的阀门来控制排水量，逐步泄洪，避免对河流下游带来直接的危害。同理，削峰填谷就是说当请求激增时MQ可以通过容纳大量的数据降低消费者的压力，同时消费者可以根据自身的消费能力从MQ中取出数据进行消费，避免了大量请求直接打到服务中，导致服务崩溃。
MQ的劣势
1、系统复杂度提高：加入MQ后，需要自己实现生产者和消费者，导致系统的复杂度提高。
2、系统可用性降低：如果MQ宕机，将会导致整个系统不可用。
3、运维成本提高：需要额外的机器运行MQ服务，以及需要人力来维护MQ服务。
4、定位问题复杂：随着系统复杂度的提高，定位问题将越来越困难。
而我们在应用MQ时主要解决的问题就是提高MQ的可用性，这个问题可以通过搭建MQ集群、增加监控提醒功能来解决。
几种MQ产品对比
| RabbitMQ | RocketMQ | Kafka | ActiveMQ |
|---|---|---|---|
| 公司/社区 | Rabbit | Alibaba（已捐献给Apache） | Apache |
| 开发语言 | Erlang | Java | Java&Scala |
| 支持的协议 | AMQP、SMTP、STOMP、XMPP | 自定义 | 自定义 |
| 支持的客户端语言 | Erlang、Java、Ruby等，几乎支持所有语言 | 主要支持Java | Java、Python、PHP等 |
| 单机吞吐量 | 万级（其次） | 十万级（最好） | 十万级（次好） |
| 消息延迟 | 微秒级 | 毫秒级 | 毫秒级 |
| 特性 | 并发能力强，性能极好，延时低，社区活跃，有强大的管理界面 | 功能完备，扩展性好 | 支持主要的MQ功能，主要应用于大数据领域 |
几种MQ产品对比
来源：oschina
链接：https://my.oschina.net/llcngu/blog/4952821