RabbitMQ_rabbitmq默认端口

默认连接端口：5672，默认web管理端口：15672
几个关键概念：
Message
消息,消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key. (路由键)、priority (相对于其他消息的优先权)、delivery-mode (指出该消息可能需要持久性存储)等。
Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。
Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
Exchange有4种类型: direct(默认)， fanout, topic,和headers,不同类型的Exchange转发消息的策略有所区别
Queue
消息队列，用来保存消息到发送给消费耆。它是消息的容嚣。也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
Exchange和Queue的绑定可以是多对多的关系。
Virtual Host
虚拟主机，相当于环境隔离，每个Virtual Host里配置自己的交换器，队列，绑定等，各个虚拟主机内的信息互相隔离。
Connection
网络连接，比如一个TCP连接。
Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接，AMQP命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所引入了信道的概念，以复用一条TCP连接。

Exchange（交换机）分发消息时根据类型的不同分发策略有区别，一共有四种类型：direct，fanout，topic, headers。headers匹配AMQP消息的header而不是路由键，headers交换器和direct交换器完全一致，但性能差很多，目前几乎已经用不到

Direct Exchange

指消息中的路由键（routing key）必须与binding中的binding key完全一致，交换器才将消息发送到对应的队列中。它是完全匹配、单播的，点对点模式。

Fanout Exchange

这种交换机不会处理routing key，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。广播模式。

Topic Exchange

topic交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符:符号“#”和符号“*”。#匹配0个或多个单词，*匹配一 个单词。订阅模式。

死信队列

死信产生的原因

1。当消息被消费者拒收，并且不让其重新入队（手动确认模式中，reject方法可以拒收方法，并且requeue参数为false）
2.消息的TTL到了，消息过期了
3.队列的长度限制满了，排在前面的消息会被丢弃或者扔到死信路由上

延时队列实现一（设置队列的过期时间）

生产者发送消息时指定特殊的路由键–》交换机根据路由键将消息发送到指定的队列–》这个队列需要设置几个参数（1.消息的存活时间 2.死信交换机（消息过期时消息会被扔到此交换机）3.死信路由键）–》当消息过期时，消息会被投递到死信交换机–》消息再次投递到跟死信队列用前一步设置的路由键绑定的队列–》监听了此队列的消费者就会收到延时消息

延时队列实现二（设置消息的过期时间）

生产者发送消息时指定此消息的过期时间–》交换机将消息发送到队列–》这个队列需要设置几个参数（1。死信交换机（消息过期时消息会被扔到此交换机）2.死信路由键）–》当消息过期时，消息会被投递到死信交换机–》消息再次投递到跟死信队列用前一步设置的路由键绑定的队列–》监听了此队列的消费者就会收到延时消息

给消息设置过期时间的缺陷

RabbitMQ内部使用的是惰性检查的机制（懒检查），比如：我们同时发送了3条消息，第一条消息5分钟到期，第二条3分钟，第三条1分钟，到第二步，交换机将消息发送到队列时，正常情况应该是1分钟过期的消息最先弹出队列，但是服务器会先检查第一条消息，检查到第一条消息是5分钟过期时，服务器就不会检查下去，而是等待5分钟过后来把第一条消息从队列里弹出，然后检查第二条，发现她已经过期，就弹出，检查第三条，发现过期，弹出。这种机制导致了后面两条早已到期的消息受限于第一条的到期时间，所以对于延时队列应该使用第一种，给队列设置过期时间的方式

消息确认机制

为了保证消息不丢失，可靠抵达，可以使用事务消息，但是性能会下降250倍，所以可以使用rabbit的消息确认机制

confirmCallback：确认模式 （publisher）

消息只要被broker接收到就会执行confirmCallback，如果是集群模式，需要被所有broker接收到才会执行confirmCallback，被broker接收到，只能表明消息已经到达服务器，不能保证一定会被投递到目标queue

returnCallback：未投递到queue时的退回模式（publisher）

只有在消息从broker投递到queue失败时（如没有对应的队列名，或队列被删除等）才会触发，成功不会触发

ack：确认机制（consumer）

默认是自动确认的，只要消息被接收到，客户端会自动确认，服务端就会移除这个消息，但是接收到不代表被我们正确的完整的消费掉，（比如我们从队列中接收到10条消息，我们程序的逻辑只消费掉一条，这时发生了宕机，这10条消息也会被自动ack，所以导致我们的消息还没被正确处理完，但服务端已经移除掉了这10条消息，发生了消息丢失），这时我们需要开启手动确认消息ack
其中confirmCallback和returnCallback属于发送端的回调确认模式，ack属于消费端的确认机制