概述
RabbitMQ 是采用 Erlang 语言实现 AMQP （Advanced Message Queuing Protocol，高级消息队列协议）的消息中间件，它最初起源于金融系统，用于在分布式系统中存储转发消息，RabbitMQ 凭借其高可靠、易扩展、高可用及丰富的功能特性受到越来越多企业的青睐。
RabbitMQ特性
-
可靠性
RabbitMQ 使用一些机制来保证可靠性， 如持久化、传输确认及发布确认等。
-
灵活的路由
在消息进入队列之前，通过交换器来路由消息，参考下文交换机（Exchange）类型。
-
扩展性
多个 RabbitMQ 节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点 。
-
高可用
队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用 。
-
多种协议
RabbitMQ 除了原生支持 AMQP 协议，还支持STOMP， MQTT等多种消息中间件协议 。
-
多语言客户端
RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C#、 JavaScript等
-
管理界面
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。
-
插件机制
RabbitMQ 提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。
RabbitMQ 的基本模型与概念
消息中间件的概念模型
所有 MQ 产品从模型抽象上来说都是一样的过程：生产者（Producer）创建消息，然后发布到队列（Queue）中，最后将消息发送到监听的消费者，消费者（Consumer）来消费队列中的消息。如下图：
具体的消息中间件 RabbitMQ 内部结构如下图：
RabbitMQ 基本概念
-
消息(Message)
消息由标签（label）和消息体（payload）组成。
标签：由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等 。
消息体：一般是一个带有业务逻辑结构的数据，比如一个JSON字符串，当然也可以进一步对这个消息体进行序列化操作。
-
生产者(Publisher/Producer)
创建消息的一方称为生产者，生产者把消息交由RabbitMQ，RabbitMQ之后会根据标签把消息发送给感兴趣的消费者 (Consumer)。
-
消费者(Consumer)
消费消息的一方称为消费者，表示一个从消息队列中取得消息的客户端应用程序。
-
队列(Queue)
消息队列用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
-
服务节点(Broker)
对于 RabbitMQ 来说，一个 RabbitMQBroker 可以简单地看作一个 RabbitMQ 服务节点， 或者 RabbitMQ 服务实例。 大多数情况下也可以将一个RabbitMQ Broker看作一台RabbitMQ服务器 。
-
虚拟主机(Virtual Host)
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的vhost是 / 。
-
交换器(Exchange)
用来接收生产者发送的消息并负责将这些消息路由给服务器中的队列，如果路由不到，则返回给生产者，或直接丢弃。
-
绑定(Binding)
RabbitMQ 中通过绑定将交换器 Exchange 与队列 Queue 关联起来，在绑定的时候一般会指定一个绑定键 (BindingKey)，这样 RabbitMQ就知道如何正确地将消息路由到队列了。
-
路由键(RoutingKey)
生产者将消息发给交换器的时候，一般会指定一个RoutingKey，用来指定这个消息的路由规则，而这个 RoutingKey需要与交换器类型和绑定键 (BindingKey) 联合使用才能最终生效。在交换器类型和绑定键 (BindingKey) 固定的情况下，生产者可以在发送消息给交换器时， 通过指定 RoutingKey来决定消息流向哪里。
-
连接(Connection)
网络连接，比如一个TCP连接。
-
信道(Channel)
多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
交换器(Exchange)类型
RabbitMQ 常用的交换器类型有 fanout、 direct、 topic、 headers 这四种 。
-
fanout
这种类型会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中，fanout 类型转发消息是最快的。
-
direct
direct 类型的交换器路由规则也很简单，它会把消息路由到那些 BindingKey 和 RoutingKey 完全匹配的队列中。
以下图为例：交换器的类型为direct，如果我们发送一条消息，并在发送消息的时候设置路由键为"warning"，则消息会路由到Queue1和Queue2
如果在发送消息的时候设置路由键为"info" 或者 "debug"，消息只会路由到Queue2。 如果以其他的路由键发送消息，则消息不会路由到这两个队列中。
-
topic
前面讲到 direct 类型的交换器路由规则是完全匹配 BindingKey 和 RoutingKey，但是这种严格的匹配方式在很多情况下不能满足实际业务的需求。 topic 类型的交换器在匹配规则上进行了扩展，它与direct类型的交换器相似，也是将消息路由到 BindingKey 和 RoutingKey 相匹配的队列中，但这里的匹配规则有些不同，它约定：
-
RoutingKey 为点号"."分隔的字符串（被点号"."分隔开的每一段独立的字符串称为一个单词如"com.rabbitmq.client"，"java.util.concurrent"、"com.hidden.client" ）；
-
BindingKey 和 RoutingKey 一样也是点号"."分隔的字符串 ；
-
BindingKey 中可以存在两种特殊字符串"*"和"#"用于做模糊匹配其中"*"用于匹配一个单词，“#”用于匹配多个单词（可以是0个） 。
例如：
-
示例：
路由键为 "com.rabbitmq.client" 的消息会同时路由到 Queue1 和 Queue2 中
路由键为 "com.hidden.client" 的消息只会路由到 Queue2 中
路由键为 "com.hidden.demo" 的消息只会路由到 Queue2 中
路由键为 "java.rabbitmq.demo" 的消息只会路由到 Queue1 中
路由键为 "java.util.concurrent" 的消息将会被丢弃或者返回给生产者(需要设置mandatory参数) ，因为它没有匹配任何路由键
-
-
headers
headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，RabbitMQ 会获取到该消息的headers，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。
RabbitMQ的运转流程
整个消息队列的运转流程大致如下：
生产者端
- 生产者连接到 RabbitMQ Broker，建立一个连接(Connection)，开启一个信道 (Channel)；
- 生产者声明一个交换器，并设置相关属性，比如交换机类型、是否持久化等；
- 生产者声明一个队列井设置相关属性，比如是否排他、是否持久化、是否自动删除等；
- 生产者通过路由键将交换器和队列绑定起来；
- 生产者发送消息至 RabbitMQ Broker，其中包含路由键、交换器等信息；
- 相应的交换器根据接收到的路由键查找相匹配的队列；
- 如果找到，则将从 生产者发送过来的消息存入相应的队列中；
- 如果没有找到，则根据生产者配置的属性选择丢弃还是回退给生产者；
- 关闭信道；
- 关闭连接。
消费者端
- 消费者连接到 RabbitMQ Broker，建立一个连接(Connection)，开启一个信道(Channel)；
- 消费者向RabbitMQ Broker请求消费相应队列中的消息，可能会设置相应的回调函数， 以及做一些准备工作；
- 等待 RabbitMQ Broker回应并投递相应队列中的消息；
- 消费者确认 (ack) 接收到的消息；
- RabbitMQ从队列中删除相应己经被确认的消息；
- 关闭信道；
- 关闭连接。
推荐阅读
如果觉得还有帮助的话，你的关注和转发是对我最大的支持，O(∩_∩)O
