目录：
（1）SpringAMQP的基本介绍
（2）SpringAMQP-入门案例的消息发送
（3） SpringAMQP-入门案例的消息接收
（4）SpringAMQP-WorkQueue模型
（5）SpringAMPQ-发布订阅模型介绍
（6）SpringAMQP-FanoutExchange
（7）SpringAMQP-DirectExchange
（8）SpringAMQP-TopicExchange
（9）SpringAMQP-消息转换器
（1）SpringAMQP的基本介绍
上面的官方提供的简单队列模型消息发送与接收的api，写起来非常的麻烦，而SpringAMQP可以大大简化消息发送和接收的api
（2）SpringAMQP-入门案例的消息发送
这里我们使用单元测试来做的，将来肯定不是单元测试，是在微服务里做业务，有人支付成功了，我想发送一个消息，在支付之后的业务里加上，发送消息的代码就可以了。
首先配置文件进行配置：
编写测试类：发送消息 ：是Springboot项目，单元 测试需要加两个注解：
对列中接收了一条消息：
进入这个对列，查看一下：
（3） SpringAMQP-入门案例的消息接收
第一步引依赖，在父工程已经做了，这里不用在引了
消费者去监听消息，Spring已经帮助我们跟MQ建立了连接，连接的事不用管了，唯一需要管的事是，我要去监听那个对列，监听到这个队列后干什么事
首先进行配置配置文件：
创建类：
这个类是Spring中的Bean，接收消息是有Spring来处理的，所以启动主启动类，就可以了：
可以看到消息接收成功了
浏览器对类中的消息就没了：消息消费完就干掉了
（4）SpringAMQP-WorkQueue模型
这里有两个消费者，有一条消息，消费者一接收到，消费完就会删除，消费者二就不会拿到这个消息，如果有50条消息，不会每个人50条，而是他两各自处理一部分，合起来是50条
只有一个消费者不行吗？比如这个消费者每秒处理40条消息，发送者每秒发送50条，那么这个消费者消费不完，每秒会多出来10个消息没人处理，这个消息怎么办呢？只能堆积在队列当中，那么队列是有存储上限的，最终会堆积满的，有两个消费者的话会不会堆积消息
从测试类里面，定义第二个方法：
消费者让他们分被睡ji
启动消息的发送者的代码：消息平均的分配给这两个消费者，消费者1拿的是偶数，消费者二拿的是奇数，它没有考虑消费者的消费能力，平均接收，这是MQ的一种机制决定的，消息的预取机制
消息预取：是先把消息都拿过来，有多小消息拿多少，不管能不能消费 这样消息会先平均的分配到消费者
在消费者的配置文件中加这个配置：每次都取一条消息，取完再拿，这样就不会出现消息先预取过来的情况了
重新启动消费者的启动类：
重新发送消息：消费者一消费了大量的消息，消费者二消费的比较慢，它只消费了几条消息
这样就起到了能者多劳的效果了，消费者一消费能力块，所以消费的消息多
（5）SpringAMPQ-发布订阅模型介绍
简单模型、工作对列模型发送的消息，他们有一个共同的特点，就是它发送的消息只能被一个消费者消费，一旦消费完就会从对列中删除
它是无法满足课程开始时的需求，用户支付完，去通知其他服务：订单服务、存储服务、短信服务，这三个服务各自去完成自己的业务，也就是说你发送的这条消息，需要被三个消费者服务都接收到 ，那怎么办？就需要用到发布与订阅
以前的模型是直接发送给对列，而这里是发送给交换机，交换机再把消息转发到队列当中，消息的发送者不需要队列的存在，交换机可以把消息转发给多个队列，如果转发给多个对列，就实现了一个消息被多个消费者消费了，到底交换机发给一个对列还是多个队列，是由交换机的类型决定的，分为三种交换机，他们只负责消息的转发
（6）SpringAMQP-FanoutExchange
交换机：
进入这个交换机：看到了绑定关系
队列：
添加：
启动消费者主启动类，运行发送者：
（7）SpringAMQP-DirectExchange
消费者：
发送者：
发送签名blue，相同的签名key才能接收消息：
换成签名key为yellow的，相同的key才能接收消息：
发送red的签名key，消费者都能接收到
（8）SpringAMQP-TopicExchange
运行
运行：
只有queue1收到消息： 
（9）SpringAMQP-消息转换器
查看消息：发现数据不对，进行了序列话，我们rabbitMQ只支持字节，Spring允许我们发object的对象，说明啊，它会将我们的对象做序列化，用的是jdk的序列化方式，这个序列化有缺点：性能比较差、安全性有问题，数据长度长
在父工程中引入依赖：
发送消息：
在主启动类中声明Bean，他也是一个配置Bean
先清除消息：
重新发送消息：
浏览器查看：
接收消息：
引来已经在父工程引入过了，创建Bean：
