概述
MQ也即是Message Queue，翻译就是消息队列，那何为消息队列就是存放消息的队列，为什么需要一个队列来存放这些消息，为什么不直接发送呢？举个例子，如果一个服务正常可以支持tps是1000，现在突然请求量达到5000，怎么办，有可能直接把服务器访问崩溃了，这时如果使用消息队列，就可以先把消息放到队列中，然后服务器慢慢处理，这叫做错峰处理，在我们实际的工作经验中，mq更多的是用在服务端需要长时间处理的场景中，因为http请求要求的时效性太高，如果服务端处理时间过长，就会导致很多的请求超时，而使用mq就可以解决这个问题。
消息队列的作用
上面概述中已经叙述了消息队列的部分功能，下面列举一下消息队列的详细作用。
- 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。
- 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）
- 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)
- 限流削峰：应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；(根据服务承受度设置队列大小，超过了就返回活动结束了，咱们经常各大商城秒杀，心里还没有点B数吗)减少压力,避免服务挂掉。
- 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))
实现消息队列的两种模式
点对点：每个消息只有一个消费者，不可重复消费，而且消费完消息就从队列中清除。
发布\订阅：每条消息有多个消费者，比如微信的订阅功能，点击订阅之后就可以不定期的给你推送，这个还分pull模式和push模式。所谓的pull模式就是消费者主动去队列消费消息，而push模式是生产者将消息发到mq之后，mq服务端马上将这条消息投递给 Consumer，优劣很容易看出，消费者按照自己的能力去拿消息处理的方式肯定更好，这也是为什么消息队列基本都使用pull模式的原因。
常用的MQ对比
我使用过的消息队列有RabbitMQ,kafka,其他的消息队列，比如ActiveMQ，RocketMQ,这两个不太熟悉，不过大同小异。对每种消息队列的性能对比感兴趣读这篇文章：中间件对比----Kafka、ActiveMQ、RabbitMQ及RocketMQ性能对比
RabbitMQ介绍
RabbitMQ架构
组件介绍
Broker:也就是服务器实体
Publisher:生产者
Virtual Host:虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域，这里需要注意一下，Exchage,Queue是和Virtual Host绑定的，一个broker中可以有多个Virtual Host
Queue:存储消息的队列
Channel:信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的 TCP 连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接
Consumer:消费者
Exchange:交换机，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。Exchange分为4中类型，direct,fanout,topic,headers,其中headers和direct交换器完全一致，但是性能比direct模式差很多，基本不用，所以直接看另外三种类型。
direct交换器
消息中的路由键（routing key）如果和 Binding 中的 binding key 一致，换器就将消息发到对应的队列中。它是完全匹配、单播的模式。
fanout模式
这种模式叫广播模式，就是一条消息路由到多个队列，很像子网广播。这种模式是不区分路由键的。
topic模式
topic 交换器通过模式匹配分配消息的路由键属性，其实这种模式和direct模式是一样的，不过direct模式是精确匹配，这个是模糊匹配，精确匹配那就只有一个队列了，模糊匹配就有可能匹配到多个队列。
根据工作经验来看，使用direct和fanout模式比较多一点，第三种方式使用的不太多。
总结
总的来说rabbitmq还是挺简单的，很稳定，在中小型的服务中推荐使用，springboot中也集成了rabbitmq，使用起来更加简单。
参考文章：https://juejin.im/post/5b32044ef265da59654c3027