目录
RabbitMQ分类
1.Hello World（直连）：生产者发送消息到消息队列，消费者消费队列中的消息
2.Work（任务模型）：让多个消费者绑定到一个队列，共同消费队列中的消息；
默认情况下rabbitmq按顺序将每个消息发送给下一个使用者，平均而言，每个消费者都会收到相同数量的消息，这种分发消息的方式称为循环；因为消息自动确认机制（autoAck : true）导致平均分配消息，这样会导致在消费消息时宕机导致数据丢失，所以关闭自动确认机制（autoAck : false），开启手动确认消息，且设置通道每次只能消费一个消息
3.Fanout（广播） ：
????????在广播模式下，消息发送流程
- 可以有多个消费者
- 每个消费者有自己的queue（队列）
- 每个队列都要绑定exchange（交换机）【routingKey不需要，因为是群发；type : fanout】
- 生产者发送的消息只能发送到交换机，交换机来决定发给哪个队列，生产者无法决定
- 交换机把消息发送给绑定过的所有队列
- 队列的消费者都能拿到消息，实现一条消息被多个消费者消费
4. Routing（路由）：
????????在Fanout模式中，一条消息会被所有订阅的队列消费，但是，在某些场景下，我们希望不同的消息被不同的队列消费，这时就要用Direct类型的Exchange
5.Topics（动态路由）：
????????Topic类型的Exchange与Direct相比，都是可以通过RoutingKey把消息路由到不同的队列。只不过Topic类型的Exchange可以让队列在绑定RoutingKey的时候使用通配符！这种模型RoutingKey一般都是由一个或多个单词组成，多个单词之间用 "," 分割
?
SpringBoot整合MQ使用
1.引入依赖
2.配置配置文件
3.发送/消费
发送
?消费（临时队列）
MQ的应用场景说明
1.异步处理：用户注册时，需要发送注册邮件和短信，串行和并行会导致增加客户等待时间，而引入消息队列后，把发送邮件，短信等不是必须的业务逻辑异步处理，提高了响应返回的时间。
2.应用解耦：双十一购物节，用户下单后，订单系统需要通知库存系统，传统做法是订单系统调用库存接口，但库存系统出现故障时，会导致订单失败。引用消息队列后，用户下单后，订单系统将消息写入消息队列，返回用户下单成功，库存系统订阅下单的消息，获取下单信息，进行库存操作，就算库存系统出现故障，也不会导致订单消息的丢失。
3.流量削峰：秒杀活动时，会因为流量过大导致应用挂掉，加入消息队列，可以控制活动人数，超过指定人数订单直接丢弃，同时，可以缓解段时间的高流量压垮应用。
集群架构
1.普通集群
????????其他节点无法复制主节点消息队列，使用其他节点时会通过主节点去查询消息队列，但主节点宕机后，其他节点无法使用...
?2.镜像集群
?