RabbitMQ目录

在本节之前，我们用的交换机都是默认交换机。

在上一节中，我们创建了一个工作队列。我们假设的是工作队列背后，每个任务都恰好交付给一个消费者（工作进程），如下图：

而在这一部分中，我们将做一些完全不同的事情—我们将消息传达给多个消费者。这种模式称为 ”发布/订阅”。它依然还是一个队列中的消息只能被一个消费者消费，但是可以使用交换机把这条消息转发给另外一个队列，进而可以让另外一个消费者消费该消息。交换机与队列的绑定关系是通过RoutingKey来确定的，不同的RoutingKey对应着不同的队列。

下面我们先来看一下交换机。

RabbitMQ 消息传递模型的核心思想是：生产者生产的消息从不会直接发送到队列。实际上，通常生产者甚至都不知道这些消息传递传递到了哪些队列中。

相反，生产者只能将消息发送到交换机(exchange)，交换机工作的内容非常简单，一方面它接收来自生产者的消息，另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们到许多队列中还是说应该丢弃它们。这些情况是由交换机的类型来决定。

总共有以下类型：

在第一节我们就说过RabbitMQ的六大模式：

简单模式、工作模式、发布确认模式

发布订阅模式、标题模式、主题模式

前三种在前面已经描述过了，前三种的讲解也都是在默认交换机的情况下（其实默认交换机的类型是direct）

而后面三种模式都是和交换机的类型紧密相关的。

在前面部分我们对 exchange 一无所知，但仍然能够将消息发送到队列。之前能实现的原因是因为我们使用的是默认交换，我们通过空字符串(“”)进行标识。

第一个参数是交换机的名称。空字符串表示默认或无名称交换机。

消息能路由发送到队列中其实是由routingKey (bindingkey) 绑定 key 指定的，如果是默认交换机，那routingKey默认就是队列名。

临时队列就是不持久化的队列。

之前的章节我们使用的是具有特定名称的队列（还记得 hello 和 ack_queue 吗？)。队列的名称我们来说至关重要：我们需要指定我们的消费者去消费哪个队列的消息。

每当我们连接到 RabbitMQ 时，我们都需要一个全新的空队列，为此我们可以创建一个具有随机名称的队列，或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接，队列将被自动删除。

创建临时队列的方式如下: String queueName = channel.queueDeclare().getQueue();

创建出来之后长成这样:

什么是 bingding 呢？binding 其实是 exchange 和 queue 之间的桥梁（交换机和队列），它告诉我们 exchange 和那个队列进行了绑定关系。比如说下面这张图告诉我们的就是 X 与 Q1 和 Q2 进行了绑定。

交换机与队列的绑定关系是通过RoutingKey来确定的，不同的RoutingKey对应着不同的队列。

Fanout 这种类型非常简单。正如从名称中猜到的那样，它是将接收到的所有消息广播到它知道的所有队列中。系统中默认有些 exchange 是Fanout 类型。

为了说明 “发布/订阅” 模式，我们将构建一个简单的日志系统。它将由两个程序组成：第一个程序将发出日志消息，第二个程序是消费者。其中我们会启动两个消费者，其中一个消费者接收到消息后把日志存储在磁盘，另外一个消费者收到消息后把消息打印在屏幕上，事实上第一个程序发出的日志消息将广播给所有消费者。

Logs（交换机的名字） 和 临时队列 的绑定关系如下图：

它们的Routing Key 都是空串。

ReceiveLogs01 将接收到的消息打印在控制台：

ReceiveLogs02 将接收到的消息存储在磁盘：

EmitLog 发送消息给两个消费者接收:

最后的效果就是两个消费者都接收到了生产者发的消息。一发多接。

在上一小节中，我们构建了一个简单的日志记录系统。我们能够向许多接收者广播日志消息。在本节我们将向其中添加一些特别的功能-比方说我们只让某个消费者订阅发布的部分消息。例如我们只把严重错误消息定向存储到日志文件(以节省磁盘空间)，同时仍然能够在控制台上打印所有日志消息。

我们再次来回顾一下什么是 bindings，绑定是交换机和队列之间的桥梁关系。也可以这么理解：队列只对它绑定的交换机的消息感兴趣。绑定用参数：routingKey 来表示也可称该参数为 binding key，

创建绑定我们用代码：channel.queueBind(queueName, EXCHANGE_NAME, “routingKey”);

绑定之后的意义由其交换类型决定。

路由模式与发布订阅模式的区别：发布订阅模式是交换机与所有的队列的routingKey都是相同的；而路由模式是交换机与每个队列都有不用的routingKey，从而实现让特定的消费者消费特定的消息。

上一节中的我们的日志系统将所有消息广播给所有消费者，对此我们想做一些改变，例如我们希望将日志消息写入磁盘的程序仅接收严重错误(errros)，而不存储哪些警告(warning)或信息(info)日志消息避免浪费磁盘空间。

Fanout（扇出）这种交换类型并不能给我们带来很大的灵活性：它只能进行无意识的广播，

在这里我们将使用 direct 这种类型来进行替换，这种类型的工作方式是，消息只去到它绑定的routingKey 队列中去，实现区别对待。

在上面这张图中，我们可以看到 X 绑定了两个队列，绑定类型是 direct。队列Q1 绑定键为 orange，队列 Q2 绑定键有两个：一个绑定键为 black，另一个绑定键为 green.

在这种绑定情况下，生产者发布消息到 exchange 上，绑定键为 orange 的消息会被发布到队列Q1。绑定键为 blackgreen 和的消息会被发布到队列 Q2，其他消息类型的消息将被丢弃。

当然如果 exchange 的绑定类型是direct，但是它绑定的多个队列的 key 如果都相同，在这种情况下虽然绑定类型是 direct 但是它表现的就和 fanout 有点类似了，就跟广播差不多，如上图所示。

上图展示的是：交换机名字为：direct_logs、两个队列名分别为：console、disk，其中队列console有个两个RoutingKey。下面来看代码：

消费者1：ReceiveLogsDirect01

消费者2：ReceiveLogsDirect02

生产者：

在上一个小节中，我们改进了日志记录系统。我们没有使用只能进行随意广播的 fanout 交换机，而是使用了 direct 交换机，从而有能实现有选择性地接收日志。

尽管使用direct 交换机改进了我们的系统，但是它仍然存在局限性：比方说我们想接收的日志类型有info.base 和 info.advantage，某个队列只想要 info.base 的消息，那这个时候direct 就办不到了。这个时候就只能使用 topic 类型。

发送到类型是 topic 交换机的消息的 routingKey 不能随意写，必须满足一定的要求：它必须是一个单词列表，以点号分隔开。这些单词可以是任意单词，比如说：“stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit”，这种类型的。当然这个单词列表最多不能超过 255 个字节。

在这个规则列表中，其中有两个替换符是大家需要注意的：

下图绑定关系如下：

上图是一个队列绑定关系图，我们来看看他们之间数据接收情况是怎么样的 quick.orange.rabbit 被队列 Q1、Q2 接收到 lazy.orange.elephant 被队列 Q1、Q2 接收到

quick.orange.fox 被队列 Q1 接收到 lazy.brown.fox 被队列 Q2 接收到 lazy.pink.rabbit 虽然满足两个绑定但只被队列 Q2 接收一次 quick.brown.fox 不匹配任何绑定不会被任何队列接收到会被丢弃 quick.orange.male.rabbit 是四个单词不匹配任何绑定会被丢弃 lazy.orange.male.rabbit 是四个单词但匹配 Q2

当队列绑定关系是下列这种情况时需要引起注意：

生产者：EmitLogTopic

消费者1：ReceiveLogsTopic01

消费者2：ReceiveLogsTopic02