MQ的优势
- 应用解耦
系统的耦合性越高，容错性就越低，可维护性就越低。使用MQ使得应用间解耦，提升容错性和可维护性。
- 异步提速
如1中图示，在订单系统处理完逻辑之后，就可以给用户反馈下单成功，后边的操作放在后台异步执行，这样减少了同步调用时的等待时间。同时，也增加了系统的吞吐量。
- 削峰填谷
提高系统的稳定性。
MQ的劣势
- 系统可用性降低
系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响，
- 系统复杂度提高
MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。那么就会引入一系列的问题，比如：如果抱枕该消息没有被重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性等等。
- 一致性问题
A系统处理自己的业务，通过MQ给B,C,D三个自行同发送消息数据，如果B,C系统处理成功，D系统处理失败，如果保证消息数据处理的一致性是一个新引入的问题。
使用MQ的场景有哪些？
1.生产者不需要从消费者处获取反馈。也就是说，生产者只是给消费者一个命令或者通知，而不需要从消费者那获得到具体的反馈，类似于udp的那种通信方式。
2.允许整个消息链路上有短暂的数据不一致的情况。这个的意思是，当上层执行完自己的操作，并下发消息给下层时，这时候的状态可能时成功的，那么下层在获取到消息执行的时候，可能会因为某些问题造成执行不成功，拿上边的例子来说就是，订单系统给用户的反馈是下单成功，但是到库存系统执行逻辑的时候，发现没有库存了，那么这时候就可能会把下单成功的状态修改成下单失败。
3.当当前系统架构不足以支撑起自己的业务时，而加入MQ之后，又能确实的起到效果的时候。
常见的MQ产品有哪些？
目前业界常用的MQ有很多，例如RabbitMQ,RocketMQ,ActiveMQ,Kafka，ZeroMQ,MeteMQ,MSMQ等等。
也有直接使用Redis来充当消息队列的案例（如我之前的文章中提到的 微服务实战 第一步从单服务到多服务），而这些消息队列产品，各有侧重，在实际选型时，需要结合自身的需求及MQ产品特征，综合考虑。
AMQP，即Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不通的开发语言等条件限制。2006年，AMQP规范发布，类似HTTP.
RabbitMQ中的相关概念
1.Broker：接受和分发消息的应用，RabbitMQ Server就是Message Broker。
2.Virtual host：出于多租户和安全因素设计的，把AMQP的基本组件划分到一个奴你的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server 提供服务的时候，可以划分出多个Vhost，每个用户在自己的Vhost中创建exchange/queue等。
3.Connection：publisher/consumer 和broker之间的TCP连接。
4.Channel：如果每次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP connection的系统开销将是巨大的，效率也会很低。Channel是在Connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个Thread创建单独的Channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是安全隔离的。Channel作为轻量级的connection极大减少了操作系统建立TCP connection的开销。
5.Exchange： message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct（point-to-point）,topic（publish-subscribe）,fanout(multicast).
6.Queue:消息存储的地方，生产者发送的消息存放在这里，等待被消费者取走。
7.Binding：exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询列表中，用于message的分发依据。
RabbitMQ的六种工作模式
简单模式，work queue，Publish/Subscribe发布订阅者模式，Routing路由模式，Topics主题模式，RPC远程调用模式
