MQ:全称Message Queue（消息队列），在消息传输过程中保存消息的容器。多用于分布式系统之间进行通信。
MQ的优势：应用解耦、异步提速、削峰填谷
MQ的劣势：可用性降低、复杂度提高
常见MQ产品
| RabbitMQ | ActiveMQ | RocketMQ | Kafka | |
| 公司/社区 | Rabbit | Appache | 阿里 | Apache |
| 开发语言 | Erlang | Java | Java | Scala&Java |
| 协议 | AMQP、AMQP | STOMP、AMQP | 自定义 | 自定义协议 |
| 支持语言 | Erlang，Java等 | Java，C，C++等 | Java，C++ | Java、PHP等 |
| 单机吞吐量 | 万级（其次） | 万级（最差） | 十万级（最好） | 十万级（次之） |
| 消息延迟 | 微妙级 | 毫秒级 | 毫秒级 | 毫秒以内 |
| 功能特性 | 并发能力强，性能极其好，延时低，社区活跃，管理界面丰富 | 老牌产品，成熟度高，文档较多 | MQ功能比较完备，扩展性佳 | 只支持主要的MQ功能，毕竟是为大数据领域准备的。 |
RabbitMQ中的相关概念：
? ? ? ? Broker:接收和分发消息的应用，RabbitMQ Server就是Message Broker；
? ? ? ? Virtual host:出于多租户和安全因素设计的，类似于namespace，虚拟的分组；
? ? ? ? Connection:连接，publisher/consumer和broker之间的TCP连接
? ? ? ? Channel:通道之间完全隔离，轻量级的Connection极大的减少了建立connection的开销；
? ? ? ? Exchange:交换机，message到达broker的第一站，分发消息到queue，类型：direct(点对点)、topic(public=subscribe)、fanout(广播)
? ? ? ? Queue:队列，消息最终被送到这里，等待consumer取走
? ? ? ? Binding:exchange和queue之间的虚拟连接，binding中可以包含routing key。是message在exchange分发的依据。
RabbitMQ的六种工作模式：
?
角色：
P:生成者，产生消息；C:消费者，接收消息；X:交换机，转发消息；Queue:消息队列，缓存消息
Exchange（交换机），一方面接收生产者发送的消息，另一方面转交消息：根据Exchange类型觉得不同的策略；
? ? ? ? Fanout：广播，将消息交给所有绑定到交换机的队列；
? ? ? ? Direct：定向，把消息交给符合指定routing key的队列；
? ? ? ? Topic：通配符，把消息交给符合routing pattern（路由模式）的队列；
Exchange（交换机）只负责装发下次，不具备存储消息的能力，因此如果没有任务队列与Exchange绑定，或者没有符合路由规则的队列，那么消息丢失！
1、Hello World（简单模式） ：一个生产者、一个消费者，不需要设置交换机（使用默认的交换机）
2、Work queues：一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认的交换机）
3、Publis/Subscribe（发布/订阅模式）:exchange=fanout,交换机和队列绑定
??
exchange类型=?Fanout 广播
场景：数据提供商
4、Routing（路由模式）：队列与交换机的绑定需要指定一个RoutingKey（路由key）消息的发送方在向Exchange发送消息时，也必须指定消息的RoutingKey。Exchange根据消息的RoutingKey判断，只有队列的RoutingKey和消息的RoutingKey完全一致，才会接受到消息；
exchange类型=?Direct：定向，把消息交给符合指定routing key的队列，一个队列可多次和exchange绑定，每次指定一个routingKey;
5、Topics（主题模式）：
routingKey一般以一个或多个单词组成，多个单词以“.”分隔 e.g.? ? ?china.hunan
通配符规则：# 匹配一个或多个词，*匹配一个词
exchange类型=?Topic：通配符，把消息交给符合routing pattern（路由模式）的队列
6、RPC（远程调用模式）：几乎不用
RabbitMQ消息确认机制：消息确认的两种状态? Confirm（投递成功） 与 Return（无队列接收）
消息投递路径：
producer--->rabbitmq broker--->exchange--->queue--->consumer
? ? ? ? 消息从producer到exchange会返回一个confirmCallback
? ? ? ? 消息从exchange到queue投递失败则会返回一个returnCallback
利用这两个callback控制消息的可靠性投递。
Confirm:生产者将消息送到Broker（容器）时产生的状态，后续会出现两种情况：
--? ack代表Broker已成功接收数据
--? nack代表Broker拒收消息，可能队列已满、限流、IO异常等
Return:消息被Broker正常接收后，但Broker没有对应的队列进行投递时产生的状态，消息被退回给生产者。
消费端收到消息后的确认方式：Consumer Ack
? ? ? ? 自动确认：acknowledge="none"，消息一经消费，则从MQ中移除。
? ? ? ? 手动确认：acknowledge="manul"
? ? ? ? 根据异常情况确认：acknowledge="auto"
手动确认，消费者收到消息，业务处理成功后，调用channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，让其自动重新发送消息。
消息可靠性保障：
? ? ? ? 持久化
? ? ? ? ? ? ? ? exchange持久化
? ? ? ? ? ? ? ? queue持久化
? ? ? ? ? ? ? ? message持久化
? ? ? ? 生成方确认confirm
? ? ? ? 消费方确认Ack
? ? ? ? Broker高可用
消费端限流:
? ? ? ? <rabbit:listener-container>中配置prefetch属性设置消费端一次拉取多少消息
? ? ? ? acknowledge="manual"，手动确认消息
TTL：time to live（存活时间/过期时间）
? ? ? ? 当消息到达存活时间后，还没有被消费，会被自动清除。可对消息、队列设置过期时间
? ? ? ? 订单系统--->MQ--->支付系统，消息30分钟过期
? ? ? ? 队列过期时间：x-message-ttl,单位ms，会对整个队列消息统一过期
? ? ? ? 消息过期时间：expiration
? ? ? ? 若果两者都进行了设置，以时间短的为准
死信队列：DLX? Dead Letter Exchange
? ? ? ? 消息成为死信的三种情况：
? ? ? ? ? ? ? ? 1、队列消息长度到达限制
? ? ? ? ? ? ? ? 2、消费者拒绝消费消息，且不把消息重新放入原目标队列
? ? ? ? ? ? ? ? 3、原队列存在消息过期设置，且消息超时未被消费
? ? ? ? 当消息成为Dead message后，可以被重新发送到另一个交换机，这个交换机就是DLX。
? ? ? ? 队列绑定死信交换机：给队列设置参数：x-dead-letter-exchange和x-dead-letter-routing-key
延迟队列：
????????消息进入队列后不会立即被消费，只有到达指定时间后，才会被消费
? ? ? ? 场景：下单后，30分钟未支付，取消订单，回滚库存
? ? ? ? ?rabbitmq中未提供延迟队列功能，可以使用TTL+死信队列组合实现延迟队列的效果
消息幂等性
? ? ? ? 幂等性值一次和多次请求某一个资源，对于资源本身应该具有相同的结果。在MQ中指，消费多条相同的消息，得到与消费该消息一次相同的结果
? ? ? ? 乐观锁：每条消息携带版本号，相同的消息，版本号相同
? ? ? ? 数据库主键
SpringBoot整合rabbitmq
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>@RabbitListener