RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。
核心概念：
Message
消息，消息是不具名的,它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成,这些属性包括routing-key(路由键) 、priority (相对于其他消息的优先权)、delivery-mode (指出该消息可能需要持久性存储)等。
Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。Exchange交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
Exchange
有4种类型： direct(默认)， fanout,，topic， 和headers，不同类型的Exchange转发消息的策略有所区别
Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多不队列。消息一置在队列里面,等待消费者连接到这个队列将其取走。
Binding
绑定，用于消息队列和交换器之间的关联，一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。Exchange 和Queue的绑定可以是多对多的关系。
Connection
网络连接，比如一个TCP连接。
Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚，拟连接,AMQP令都是通过信道爱出去的,不管是发希消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所以引入了信道的概态，以复用一条TCP连接。
Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证密环境的独立服务器域。每个vhost本质上就是一个mini版的RabbitMQ服务器，自己的队列、交换器、绑定和权限机制。vhost是AMQP概念的基础，必须在连接时RabbitMQ默认的vhost是/。
Broker
表示消息队列服务器实体
2 RabbitMQ运行机制 2.1 AMQP 中的消息路由AMQP中消息的路由过程和Java开发者熟悉的JMS存在些差别，AMQP 中增加了Exchange 和Binding 角色。生产者把消息发布到Exchange上，消息最终到达队列并被消费者接收，而Binding 决定交换器的消息应该发送到那个队列。
2.2 Exchange类型Exchange分发消息时根据类型的不同分发策略有区别，目前共四种类型：direct， fanout， topic， headers， headersAMQP 消息header而不是路由键headers交换器和 direct交换器完全一致，但性能差很多，目前几乎用不到了，所以直接着另外三种类型：
（1）Direct Exchange
标消息中的路由键(routing key)如果和Binding中的bindingkey一致，交换器就将消息发到对应的队列中。路由键与队,列名完全匹配，如果一个队列绑定到交换机要求路由键为"dog"，则只转发routing key标记为"dog"的消息，不会转发"dog.puppy"，也不会转发"dog.guard"等等。它是完全匹配、单播的模式。
（2）Fanout Exchange
每个发到fanout类型交换器的消息都会分到所有绑定的队列上去。fanout交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout类型转发消息是最快的。
（3）Topic Exchange
topic交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符：符号"#"和符号"*"匹配0个或多个单词，*匹配一个单词。
3 RabbitMQ整合（1）引入apring-boot-starter-amqp
（2）application.yml配置
（3）测试RabbitMQ
AmpqAdmin：管理组件
RabbitTemplate：消息发送处理组件
4 RabbitMQ消息确认机制---可靠抵达保证消息不丢失，可靠抵达，可以使用事务消息，性能下降250倍，为此引入确认机制publisher confirmCallback 确认模式publisher returnCallback 未投递到 queue 退回模式consumer ack机制
4.1 可靠抵达---ConfirmCallbackspring.rabbitmq.publisher-confirms=true
---在创建 connectionFactory 的时候设置PublisherConfirms(true)选项，开启/confirm/icallback。
---CorrelationData：用来表示当前消息唯一性。
---消息只要被broker接收到就会执行 /confirm/iCallback，如果是cluster模式，需要所有broker接收到才会调用 /confirm/iCallback。
---被broker接收到只能表示message已经到达服务器，并不能保证消息定会被投递到目标queue里。所以需要用到接下来的returnCallback。
4.2 可靠抵达---Ack消息确认机制消费者获取到消息，成功处理，可以回复Ack给Broker
-basic.ack用于肯定确认；broker将移除此消息
-basic.nack用于否定确认；可以指定broker是否丢弃此消息，可以批量
-basic.reject用于否定确认；同上，但不能批量
默认自动ack，消息被消费者收到，就会从broker的queue中移除queue无消费者，消息依然会被存储，直到消费者消费消费者收到消息，默认会自动ack。但是如果无法确定此消息是否被处理完成，或者成功处理。我们可以开启手动ack模式
-消息处理成功， ack()，接受下一个消息，此消息broker就会移除
-消息处理失败，nack()/reject()，重新发送给其他人进行处理，或者容错处理后ack
-消息一直没有调用ack/nack方法，broker认为此消息正在被处理，不会投递给别人，此时客户端断开，消息不会被broker移除，会投递给别人
5 RabbitMQ延时队列（实现定时任务）场景：比如未付款订单，超过一定时间后，系统自动取消订单并释放占有物品。
常用解决方案：spring的 schedule定时任务轮询数据库
缺点：消耗系统内存、增加了数据库的压力、存在较大的时间误差
解决：rabbitmq的消息TTL和死信Exchange结合
