是什么：微服务之间的消息通信方式
实现方式：AMQP （只是一种协议所以支持跨平台）与jms（java 必须是语言）
好处：
1、解耦
2、灵活性，峰值处理好
3、可恢复性
4、顺序保证
5、缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，对于秒杀业务来说尤为重要
执行原理：
消息生产方推送消息到队列，消息放消费队列中的消息。（下图是基本消费模型）
消息模型：*******重要******
基本消息模型 消息发送方 -----》队列 ------》 一个消息消费方
work 消息模型 消息发送方 -----》 队列 ------》 多个消息消费方
消息发送流程：
1） 一个队列绑定多个消费者
2）消费者呈合作者分别处理一部分消息解决消息堆积问题。
发布订阅消息模型（该模型包含基本与work 消息模型的）： 消息发布方 -->交换机 -->队列 -->消息订阅方
一、Fanout：在广播模式下，消息发送流程是这样的：
-
1） 消息生产方生产消息发送到交换机
-
2） 消费方监听queue（队列）
-
3） 队列与Exchange（交换机）绑定
-
4） 生产者发送的消息发送到交换机（在代码中将队列与交换机绑定就发送给对应队列，生产者无法决定）。
-
5） 交换机把消息发送给绑定过的所有队列
-
6） 队列中的消息被消费者监听到从而执行。实现一条消息被多个消费者消费
二、Direct：控制发布的消息的队列被哪些订阅方收到。
特点： 消息生产方会指定routingKey 的关键字，这样交换机就会将消息发送给与该routingkey完全匹配的队列。
例如：
在路由模式中，我们将添加一个功能 - 我们将只能订阅一部分消息。 例如，我们只能将重要的错误消息引导到日志文件（以节省磁盘空间），同时仍然能够在控制台上打印所有日志消息。但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。
P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key。
X：Exchange（交换机），接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列
C1：消费者，其所在队列指定了需要routing key 为 error 的消息
C2：消费者，其所在队列指定了需要routing key 为 info、error、warning 的消息
三、Topic模型 : 和Direct 一样。只是可以使用通配符进行匹配
面试热点：
一、如何保证消息不丢失？ 问到过！
1、采用消费者消息确认机制（ACK），ACK分为手动和自动，
自动ACK：消费方接受到消息则队列中的消息就会被删除
手动ACK：如果在接受到消息后发生了错误抛异常 这种情况应该使用手动确认 类似手动启动关闭事务这样
2、采用生产者消息回执确认机制：
当消费方消费消息后将会给MQ发送一个消息回执，MQ发回生产者，回执成功返回true 反之false.
二、如果MQ服务器挂掉怎么办？
1、搭建集群
2、将消息持久化，在spring集成中消息和队列以及交换机 都是持久化的
三、如何解决队列中的消息积压过大？
work 消息模型 配置多台消息的消费方进行消费。
四、幂等性（统一接口被重复执行，其结果一致）： 问到过！
消息被重复发送，例如下订单我点了两次也许是网络原因我点了2次，或者是我真的要充值两次
解决方案：
1、规定在一定时间类判断消息是否重复例如1S内进行检查是否是同一订单。
2、给消息设置标志位，如果消息被消费过一次了。还有重复的消息就考虑是否不让他继续消费了。