一文让你搞懂RabbitMQ基本概念，带你入门RabbitMQ

RabbitMQ

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，Erlang语言在数据交互方面性能优秀，有着和原生Socket一样的延迟，这也是RabbitMQ高性能的原因所在。而集群和故障转移是构建在开放电信平台框架上的。

RabbitMQ是目前非常热门的一款消息中间件，在许多场景下都可以使用，作为一名合格的开发者，有必要对RabbitMQ有所了解。

RabbitMQ作用

消息系统允许软件、应用相互连接和扩展．这些应用可以相互链接起来组成一个更大的应用，或者将用户设备和数据进行连接．消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶．

或许你正在考虑进行数据投递，非阻塞操作或推送通知。或许你想要实现发布／订阅，异步处理，或者工作队列。所有这些都可以通过消息系统实现。

RabbitMQ是一个消息代理 - 一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息在传输过程中的安全。

RabbitMQ的特点

可靠性： RabbitMQ使用一些机制来保证消息的可靠性，如持久化、传输确认及发布确认等。

灵活的路由： 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。

扩展性： 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。

高可用性： 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用。

支持多种协议： RabbitMQ 除了原生支持 AMQP 协议，还支持 STOMP、MQTT 等多种消息中间件协议。

多语言客户端： RabbitMQ几乎支持所有常用语言，比如 Java、Python、Ruby、PHP、C#、JavaScript等。

易用的管理界面： RabbitMQ提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。在安装 RabbitMQ 的时候会介绍到，安装好 RabbitMQ 就自带管理界面。

插件机制： RabbitMQ 提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。感觉这个有点类似 Dubbo 的 SPI机制。

RabbitMQ 是基于 AMQP 协议实现的，所以下面我们了解下 AMQP 协议

AMQP

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准 高级消息队列协议（二进制应用层协议），是应用层协议的一个开放标准,为面向消息的中间件设计，兼容 JMS（JAVA Message Service,java消息服务）。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件产品，不同的开发语言等条件的限制。AMQP（高级消息队列协议）是一个网络协议。它支持符合要求的客户端应用（application）和消息中间件代理（messaging middleware broker）之间进行通信。

AMQP工作流程

消息代理（message brokers）从发布者（publishers）亦称生产者（producers）那儿接收消息，并根据既定的路由规则把接收到的消息发送给处理消息的消费者（consumers）。

由于AMQP是一个网络协议，所以这个过程中的发布者，消费者，消息代理 可以存在于不同的设备上。

RabbitMQ所使用的是 AMQP 0-9-1版本。所以下面我们来介绍一下 AMQP 0-9-1模型

AMQP 0-9-1 模型

AMQP 0-9-1的工作过程如下图：消息（message）被发布者（publisher）发送给交换机（exchange），交换机常常被比喻成邮局或者邮箱。然后交换机将收到的消息根据路由规则分发给绑定的队列（queue）。最后AMQP代理会将消息投递给订阅了此队列的消费者，或者消费者按照需求自行获取。

以下是AMQP 0-9-1的 模型图

发布者（publisher）发布消息时可以给消息指定各种消息属性（message meta-data）。有些属性有可能会被消息代理（brokers）使用，然而其他的属性则是完全不透明的，它们只能被接收消息的应用所使用。

从安全角度考虑，网络是不可靠的，接收消息的应用也有可能在处理消息的时候失败。基于此原因，AMQP模块包含了一个消息确认（message acknowledgements）的概念：当一个消息从队列中投递给消费者后（consumer），消费者会通知一下消息代理（broker），这个可以是自动的也可以由处理消息的应用的开发者执行。当“消息确认”被启用的时候，消息代理不会完全将消息从队列中删除，直到它收到来自消费者的确认回执（acknowledgement）。

在某些情况下，例如当一个消息无法被成功路由时，消息或许会被返回给发布者并被丢弃。或者，如果消息代理执行了延期操作，消息会被放入一个所谓的死信队列中。此时，消息发布者可以选择某些参数来处理这些特殊情况。

队列，交换机和绑定统称为AMQP实体（AMQP entities）。

下面我们回到RabbitMQ，看一下RabbitMQ 的模型

RabbitMQ 模型

以下是一个RabbitMQ 的整体模型，跟AMQP 是差不多的。

Producer：消息生者，将消息发送到MQ

Consumer：消费者，消息会被相应的消费者进行消费处理

消息：消息一般由 2 部分组成：消息头（或者说是标签 Label）和 消息体。消息体也可以称为 payLoad ,消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括 routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。生产者把消息交由 RabbitMQ 后，RabbitMQ 会根据消息头把消息发送给感兴趣的 Consumer(消费者)。

Queue(消息队列)

Queue(消息队列)是消息的容器，它们存储着即将被消费者消费掉的消息。一个消息可投入一个或多个队列。队列跟交换机共享某些属性，但是队列也有一些另外的属性。

如下：

Name（名称）
Durable（消息代理重启后，队列依旧存在）
Exclusive（只被一个连接（connection）使用，而且当连接关闭后队列即被删除）
Auto-delete（当最后一个消费者退订后会被删除）
Arguments（一些消息代理用他来完成类似与TTL的某些额外功能）

队列在声明（declare）后才能被使用。如果一个队列尚不存在，声明一个队列会创建它。如果声明的队列已经存在，并且属性完全相同，那么此次声明不会对原有队列产生任何影响。如果声明中的属性与已存在队列的属性有差异，那么一个错误代码为406的通道级异常就会被抛出。

持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。没有被持久化的队列称作暂存队列（Transient queues）。并不是所有的场景和案例都需要将队列持久化。倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明。无论队列是否持久化，只有经过持久化的消息才能被重新恢复。

注意：持久化的队列并不会使得路由到它的消息也具有持久性！

多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理（即一个消息只会给到一个消费者进行消费），而不是每个消费者都收到所有的消息并处理，这样避免的消息被重复消费。

Exchange

Exchange：交换机，交换机是用来发送消息的一个实体。在 RabbitMQ 中，消息并不是直接发送到消息队列（Queue），而是通过Exchange交换机的规则来将消息发送到某个消息队列。交换机拿到一个消息之后会将它路由给某个队列（Queue）。它使用哪种路由算法是由交换机类型和被称作绑定（bindings）的规则所决定的。如果路由不到，或许会返回给 Producer(生产者) ，或许会被直接丢弃掉 。

交换机可以有两个状态：持久（durable）、暂存（transient）。持久化的交换机会在消息代理（broker）重启后依旧存在，而暂存的交换机则不会（它们需要在代理再次上线后重新被声明）。然而并不是所有的应用场景都需要持久化的交换机。

生产者将消息发给交换器的时候，一般会指定一个 RoutingKey(路由键)，用来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。

RabbitMQ 的 Exchange(交换器) 有以下4种类型：

直连型交换机（direct exchange）

直连型交换机（direct exchange）是根据消息携带的路由键（routing key）将消息投递给对应队列的。直连交换机用来处理消息的单播路由（unicast routing）。下边介绍它是如何工作的：

1、将一个队列绑定到某个交换机上，同时给该队列绑定一个绑定键（Binding Key）

2、当一个携带着路由键为XXX的消息被发送给直连交换机时，交换机会把它路由给绑定值同样为XXX的队列。

即消息只会投递到绑定键与它路由键相同的队列中。

注意：此交换机下，RabbitMQ 消息的负载均衡是发生在消费者（consumer）之间的，而不是队列（queue）之间。

扇型交换机（funout exchange）

扇型交换机（funout exchange）将消息路由给绑定到它身上的所有队列，而不理会绑定的路由键。如果N个队列绑定到某个扇型交换机上，当有消息发送给此扇型交换机时，交换机会将消息的拷贝分别发送给这所有的N个队列。扇型用来交换机处理消息的广播路由（broadcast routing）。

即把所有发送到该Exchange的消息路由到所有与它绑定的Queue中。

主题交换机（topic exchanges）

主题交换机（topic exchanges）通过对消息的路由键和队列到交换机的绑定模式之间的匹配，将消息路由给一个或多个队列。主题交换机经常用来实现各种分发/订阅模式及其变种。主题交换机通常用来实现消息的多播路由（multicast routing）。

当一个问题涉及到那些想要有针对性的选择需要接收消息的 多消费者/多应用（multiple consumers/applications） 的时候，主题交换机都可以被列入考虑范围。

匹配规则：

一个点号“．”分隔的字符串为一个单词（被点号“．”分隔开的每一段独立的字符串称为一个单词）

* ：它能替代一个单词（单词是一个组合，而不是说是一个字母）

#：它能替代0或多个单词

例：

*.a      可以匹配  com.a，bom.a

com.#  可以匹配com，com.a，com.b

头交换机（headers exchange）

头交换机使用多个消息属性来代替路由键建立路由规则。通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，RabbitMQ会获取到该消息的 headers（也是一个键值对的形式)'对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。

有时消息的路由操作会涉及到多个属性，此时使用消息头就比用路由键更容易表达，头交换机（headers exchange）就是为此而生的。头交换机使用多个消息属性来代替路由键建立路由规则。通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。

我们可以绑定一个队列到头交换机上，并给他们之间的绑定使用多个用于匹配的头（header）。这个案例中，消息代理得从应用开发者那儿取到更多一段信息，换句话说，它需要考虑某条消息（message）是需要部分匹配还是全部匹配。上边说的“更多一段消息”就是"x-match"参数。当"x-match"设置为“any”时，消息头的任意一个值被匹配就可以满足条件，而当"x-match"设置为“all”的时候，就需要消息头的所有值都匹配成功。

头交换机可以视为直连交换机的另一种表现形式。头交换机能够像直连交换机一样工作，不同之处在于头交换机的路由规则是建立在头属性值之上，而不是路由键。路由键必须是一个字符串，而头属性值则没有这个约束，它们甚至可以是整数或者哈希值（字典）等。

Broker

Broker：消息队列服务器实体，相当于一个 RabbitMQ 应用程序。

连接

连接（Connection）：连接RabbitMQ和应用服务器的TCP连接。

通道

通道（Channel）：连接里的一个虚拟通道。当你通过消息队列发送或者接收消息时，这个操作都是通过通道进行的。

有些应用需要与AMQP代理建立多个连接。无论怎样，同时开启多个TCP连接都是不合适的，因为这样做会消耗掉过多的系统资源并且使得

防火墙的配置更加困难。AMQP 0-9-1提供了通道（channels）来处理多连接，可以把通道理解成共享一个TCP连接的多个轻量化连接。

在涉及多线程/进程的应用中，为每个线程/进程开启一个通道（channel）是很常见的，并且这些通道不能被线程/进程共享。

RabbitMQ 工作流程

1、消息生产者连接到RabbitMQ Broker，创建connection，开启channel。

2、生产者声明交换机类型、名称、是否持久化等。

3、发送消息，并指定消息是否持久化等属性和routing key。

4、exchange收到消息之后，根据routing key路由到跟当前交换机绑定的相匹配的队列里面。

5、消费者监听接收到消息之后开始业务处理，然后发送一个ack确认告知消息已经被消费。

6、RabbitMQ Broker收到ack之后将对应的消息从队列里面删除掉。