-
RabbitMQ是使用Erlang语言来编写的，基于AMQP协议，是跨平台、跨语言的一个消息代理和队列服务器。
-
高性能的原因：Erlang语言，面向并发的编程语言。使用于交换机领域，进行数据交互的性能十分优秀。有与原生Socket一样的延迟
AMQP：Advanced Message Queuing Protocol（高级消息队列协议）。基于二进制的协议。一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计
生产消费者模式与订阅发布模式是使用消息中间件时常用的两种模式
RabbitMQ是基于AMQP协议来实现的消息中间件。AMQP，类似于HTTP协议，也是一个应用层的协议，网络层使用TCP来通信
消息发布接收流程：
-----发送消息----
生产者和Broker建立TCP连接。
生产者和Broker建立通道。
生产者通过通道消息发送给Broker，由Exchange将消息进行转发。
Exchange将消息转发到指定的Queue（队列）
----接收消息----
消费者和Broker建立TCP连接 。
消费者和Broker建立通道。
消费者监听指定的Queue（队列）
当有消息到达Queue时Broker默认将消息推送给消费者。
消费者接收到消息。
---------------------
生产者生产出Message并投递到Exchange上。
一个Exchange可以绑定多个Message Queue，它根据路由策略（routing key）路由到指定的队列。
最后由消费端去监听队列
Connection
就是一个TCP的连接。Producer和Consumer都是通过TCP连接到RabbitMQ Server的。以后我们可以看到，程序的起始处就是建立这个TCP连接
Channel
虚拟连接。它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。
那么，为什么使用Channel，而不是直接使用TCP连接？
对于OS来说，建立和关闭TCP连接是有代价的，频繁的建立关闭TCP连接对于系统的性能有很大的影响，而且TCP的连接数也有限制，这也限制了系统处理高并发的能力。但是，在TCP连接中建立Channel是没有上述代价的。对于Producer或者Consumer来说，可以并发的使用多个Channel进行Publish或者Receive。有实验表明，1s的数据可以Publish10K的数据包。当然对于不同的硬件环境，不同的数据包大小这个数据肯定不一样，但是我只想说明，对于普通的Consumer或者Producer来说，这已经足够了
相关定义：
-
Broker： 简单来说就是消息队列服务器实体
-
Exchange： 消息交换机，它指定消息按什么规则，路由到哪个队列
-
Queue： 消息队列载体，每个消息都会被投入到一个或多个队列
-
Binding： 绑定，它的作用就是把exchange和queue按照路由规则绑定起来
-
Routing Key： 路由关键字，exchange根据这个关键字进行消息投递
-
VHost： 虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
-
Producer： 消息生产者，就是投递消息的程序
-
Consumer： 消息消费者，就是接受消息的程序
-
Channel： 消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务
-
Message：消息，服务器和应用程序之间传递的数据。由Properties和Body组成。Properties可以对消息进行修饰，如消息的优先级、延迟等高级特性，Body是消息体的内容。
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
Connection Factory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接，它封装了socket协议相关部分逻辑。Connection Factory则是Connection的制造工厂。
Channel是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等
Queue（队列）是RabbitMQ的内部对象，用于存储消息
RabbitMQ中的消息都只能存储在Queue中，生产者生产消息并最终投递到Queue中，消费者可以从Queue中获取消息并消费
多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理
Message acknowledgment
在实际应用中，可能会发生消费者收到Queue中的消息，但没有处理完成就宕机（或出现其他意外）的情况，这种情况下就可能会导致消息丢失。为了避免这种情况发生，我们可以要求消费者在消费完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执（Message acknowledgment）后才将该消息从Queue中移除。
如果RabbitMQ没有收到回执并检测到消费者的RabbitMQ连接断开，则RabbitMQ会将该消息发送给其他消费者（如果存在多个消费者）进行处理。这里不存在timeout，一个消费者处理消息时间再长也不会导致该消息被发送给其他消费者，除非它的RabbitMQ连接断开。
这里会产生另外一个问题，如果我们的开发人员在处理完业务逻辑后，忘记发送回执给RabbitMQ，这将会导致严重的bug——Queue中堆积的消息会越来越多。消费者重启后会重复消费这些消息并重复执行业务逻辑。
另外publish message 是没有ACK的
Message durability
如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。但依然解决不了小概率丢失事件的发生（比如RabbitMQ服务器已经接收到生产者的消息，但还没来得及持久化该消息时RabbitMQ服务器就断电了），如果我们需要对这种小概率事件也要管理起来，那么我们要用到事务
Prefetch count
前面我们讲到如果有多个消费者同时订阅同一个Queue中的消息，Queue中的消息会被平摊给多个消费者。这时如果每个消息的处理时间不同，就有可能会导致某些消费者一直在忙，而另外一些消费者很快就处理完手头工作并一直空闲的情况。我们可以通过设置Prefetch count来限制Queue每次发送给每个消费者的消息数，比如我们设置prefetchCount=1，则Queue每次给每个消费者发送一条消息；消费者处理完这条消息后Queue会再给该消费者发送一条消息
Exchange
生产者将消息发送到Exchange（交换器，由Exchange将消息路由到一个或多个Queue中（或者丢弃）
RabbitMQ中的Exchange有四种类型，不同的类型有着不同的路由策略
Routing Key
生产者在将消息发送给Exchange的时候，一般会指定一个Routing Key，来指定这个消息的路由规则，而这个Routing Key需要与Exchange Type及Binding key联合使用才能最终生效。
在Exchange Type与Binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定Routing Key来决定消息流向哪里。
RabbitMQ为Routing Key设定的长度限制为255 bytes
Binding
RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到指定的Queue了
Binding key
在绑定（Binding）Exchange与Queue的同时，一般会指定一个Binding key。消费者将消息发送给Exchange时，一般会指定一个Routing Key。当Binding key与Routing Key相匹配时，消息将会被路由到对应的Queue中。
在绑定多个Queue到同一个Exchange的时候，这些Binding允许使用相同的Binding key。
Binding key并不是在所有情况下都生效，它依赖于Exchange Type，比如fanout类型的Exchange就会无视Binding key，而是将消息路由到所有绑定到该Exchange的Queue
Exchange Types
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers这四种（AMQP规范里还提到两种Exchange Type，分别为system与自定义，这里不予以描述），下面分别进行介绍。
fanout
fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中
direct
direct类型的Exchange路由规则也很简单，它会把消息路由到那些Binding key与Routing key完全匹配的Queue中
以上图的配置为例，我们以routingKey="error"发送消息到Exchange，则消息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ自动生成的Queue名称）和Queue2（amqp.gen-Agl…）；如果我们以Routing Key="info"或routingKey="warning"来发送消息，则消息只会路由到Queue2。如果我们以其他Routing Key发送消息，则消息不会路由到这两个Queue中
topic
前面讲到direct类型的Exchange路由规则是完全匹配Binding Key与Routing Key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到Binding Key与Routing Key相匹配的Queue中，但这里的匹配规则有些不同，它约定：
Routing Key为一个句点号“.”分隔的字符串（我们将被句点号". "分隔开的每一段独立的字符串称为一个单词），如"stock.usd.nyse"、"nyse.vmw"、"quick.orange.rabbit"。Binding Key与Routing Key一样也是句点号“. ”分隔的字符串。
Binding Key中可以存在两种特殊字符"*"与"#"，用于做模糊匹配，其中"*"用于匹配一个单词，"#"用于匹配多个单词（可以是零个）
以上图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey
headers
headers类型的Exchange不依赖于Routing Key与Binding Key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。
在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对。如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue
RPC
MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。
但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC
RabbitMQ中实现RPC的机制是：
客户端发送请求（消息）时，在消息的属性（Message Properties，在AMQP协议中定义了14种properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）。服务器端收到消息处理完后，将生成一条应答消息到replyTo指定的Queue，同时带上correlationId属性。客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，根据执行结果进行后续业务处理
使用ACK确认Message的正确传递
默认情况下，如果Message 已经被某个Consumer正确的接收到了，那么该Message就会被从Queue中移除。当然也可以让同一个Message发送到很多的Consumer。
如果一个Queue没被任何的Consumer Subscribe（订阅），当有数据到达时，这个数据会被cache，不会被丢弃。当有Consumer时，这个数据会被立即发送到这个Consumer。这个数据被Consumer正确收到时，这个数据就被从Queue中删除。
那么什么是正确收到呢？通过ACK。每个Message都要被acknowledged（确认，ACK）。我们可以显示的在程序中去ACK，也可以自动的ACK。如果有数据没有被ACK，那么RabbitMQ Server会把这个信息发送到下一个Consumer。
如果这个APP有bug，忘记了ACK，那么RabbitMQ Server不会再发送数据给它，因为Server认为这个Consumer处理能力有限。而且ACK的机制可以起到限流的作用（Benefitto throttling）：在Consumer处理完成数据后发送ACK，甚至在额外的延时后发送ACK，将有效的balance Consumer的load。
当然对于实际的例子，比如我们可能会对某些数据进行merge，比如merge 4s内的数据，然后sleep 4s后再获取数据。特别是在监听系统的state，我们不希望所有的state实时的传递上去，而是希望有一定的延时。这样可以减少某些IO，而且终端用户也不会感觉到
Creating a queue
Consumer和Procuder都可以通过 queue.declare 创建queue。对于某个Channel来说，Consumer不能declare一个queue，却订阅其他的queue。当然也可以创建私有的queue。这样只有APP本身才可以使用这个queue。queue也可以自动删除，被标为auto-delete的queue在最后一个Consumer unsubscribe后就会被自动删除。那么如果是创建一个已经存在的queue呢？那么不会有任何的影响。需要注意的是没有任何的影响，也就是说第二次创建如果参数和第一次不一样，那么该操作虽然成功，但是queue的属性并不会被修改。
那么谁应该负责创建这个queue呢？是Consumer，还是Producer？
如果queue不存在，当然Consumer不会得到任何的Message。那么Producer Publish的Message会被丢弃。所以，还是为了数据不丢失，Consumer和Producer都try to create the queue！反正不管怎么样，这个接口都不会出问题。
queue对load balance的处理是完美的。对于多个Consumer来说，RabbitMQ 使用循环的方式（round-robin）的方式均衡的发送给不同的Consumer
Virtual hosts
每个virtual host本质上都是一个RabbitMQ Server，拥有它自己的queue，exchagne，和bings rule等等。这保证了你可以在多个不同的Application中使用RabbitMQ
Return消息机制
用于处理一些不可路由的消息
有一个关键配置项：
Mandatory：true，则监听器会接收到路由不可达的消息，然后进行处理；false，Broker会自动删除该消息。默认是false
消息的生产者通过制定Exchange和RoutingKey，把消息投递到某一个队列中，消费者监听队列，进行消费。
但在一些情况下，发送消息时，Exchange不存在或RoutingKey路由不到，Return Listener就会监听这种不可达的消息，然后进行处理
消费端限流的概念
当巨量消息瞬间全部推送时，单个客户端无法同时处理这些数据，服务器容易故障。因此要进行消费端限流
RabbitMQ提供了一种Qos（服务质量保证）功能，即在非自动确认前提下，如果一定数目的消息未被确认前（通过consume或者channel设置Qos值），不进行消费新消息
void basicQos(int prefetchSize, int prefetchCount, boolean global) throws IOException;
prefetchSize：消息限制大小，一般为0，不做限制。
prefetchCount：一次处理消息的个数，一般设置为1
global：一般为false。true，在channel级别做限制；false，在consumer级别做限制
限流需要设置channel.basicQos(0, 1, false);
关闭autoAck，且需要手动签收。
在重写的handleDelivery方法中，如果没有进行手动签收channel.basicAck()，
那么消费端在接收消息时，因为prefetchCount设置为1，只会接收1条消息，剩下的消息的等待中，并不会被推送，直到手动ack后
消费端ACK与重回队列机制
消费端的手工ACK和NACK：
消费端进行消费时，可能由于业务异常，会调用NACK拒绝确认，而到了一定次数，就直接ACK，将异常消息进行日志的记录，然后进行补偿。
由于服务器宕机等严重问题，消费端没消费成功，重发消息后，需要手工ACK保障消费端消费成功。
消费端的重回队列：
将没有处理成功的消息重新回递给Broker。 所以，任何异常都要捕获返回ConsumeConcurrentlyStatus.RECONSUME_LATER，rocketmq会放到重试队列
重试的消息在延迟的某个时间点（默认是10秒，业务可设置）后，再次投递到这个ConsumerGroup。而如果一直这样重复消费都持续失败到一定次数（默认16次），就会投递到DLQ死信队列，此时需要人工干预了
一般在实际应用中，会关闭重回队列
TTL队列
TTL：Time To Live，生存时间。
可以指定消息的过期时间。
可以指定队列的过期时间，从消息入队列开始计算，超过了队列的超时时间设置，那么消息会自动清除
死信队列
DLX：Dead-Letter-Exchange
当消息在队列中变成死信时，能被重新publish到另一个Exchange，该Exchange就是DLX。
发生死信队列的情况：
消息被拒绝（basic.reject/ basic.nack）并且requeue=false（没有重回队列）
消息TTL过期
队列达到最大长度
死信队列的设置：
正常声明交换机，队列并绑定，需要在队列上设置一个参数：arguments.put("x-dead-letter-exchange", "dlx.exchange");
声明死信队列的Exchange和Queue，然后进行绑定：
Exchange: dlx.exchange
Queue: dlx.queue
RoutingKey: #
在消息过期、requeue、队列达到最大长度时（即为死信），消息会发送到指定的dlx.exchange交换机上，消费者会监听该交换机所绑定的死信队列
rabbitmq本身是没有绝对的消息顺序机制的，单个queue在多消费者下不能保证其先后顺序。 另外ack的机制会触发消息重复消费的
关于消息的重复执行
消费任务类型最好要支持幂等性
构建一个map来记录任务的执行情况
一句话，要不保证消息幂等性，要不就用map记录任务状态
关于消息的绝对顺序执行
我们遇到的大多数场景都不需要消息的有序的，如果对于消息顺序敏感，那么我们这里给出的方法是 消息体通过hash分派到队列里，每个队列对应一个消费者，多分拆队列
镜像队列Mirrored queue
在集群环境中,队列只有元数据会在集群的所有节点同步,但队列中的数据只会存在于一个节点，数据没有冗余且容易丢，甚至在durable的情况下,如果所在的服务器节点宕机，就要等待节点恢复才能继续提供消息服务
息会在rabbitmq节点之间的被创建为“镜像队列”的队列之间复制。和其它的主从设计一样,镜像队列也有master和slave的概念，一旦某个节点当掉,会在其余的节点中选举一个slave作为master。
在镜像队列(Mirrored Queue)中，只有master的copy对外提供服务，而其他slave copy只提供备份服务，在master copy所在节点不可用时，选出一个slave copy作为新的master继续对外提供服务