rabbitMQ 基本概念

RabbitMQ 整体上是一个生产者与消费者模型，主要负责接收、存储和转发消息。可以把消

息传递的过程想象成:当你将一个包裹送到邮局，邮局会暂存并最终将邮件通过邮递员送到收
件人的手上， RabbitMQ 就好比由邮局、邮箱和邮递员组成的一个系统。从计算机术语层面来说，
RabbitMQ 模型更像是一种交换机模型。

生产者和消费者

Producer: 生产者，就是投递消息的一方。
生产者创建消息，然后发布到RabbitMQ 中。消息一般可以包含2 个部分:消息体和标签
（Label）。消息体也可以称之为payload ，在实际应用中，消息体一般是一个带有业务逻辑结构
的数据，比如一个JSON 字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签

用来表述这条消息， 比如一个交换器的名称和一个路由键。生产者把消息交由RabbitMQ ，
RabbitMQ 之后会根据标签把消息发送给感兴趣的消费者C Consumer ) 。

Consumer: 消费者， 就是接收消息的一方。

消费者连接到RabbitMQ 服务器，并订阅到队列上。当消费者消费一条消息时， 只是消费
消息的消息体(payload ) 。在消息路由的过程中， 消息的标签会丢弃， 存入到队列中的消息只
有消息体，消费者也只会消费到消息体， 也就不知道消息的生产者是谁，当然消费者也不需要
知道。

Broker: 消息中间件的服务节点。

对于RabbitMQ 来说， 一个RabbitMQ Broker 可以简单地看作一个RabbitMQ 服务节点，
或者RabbitMQ 服务实例。大多数情况下也可以将一个RabbitMQ Broker 看作一台RabbitMQ
服务器。

首先生产者将业务方数据进行可能的包装， 之后封装成消息， 发送( AMQP 协议里这个动
作对应的命令为Basic.Publish) 到Broker 中。消费者订阅并接收消息(AMQP 协议里这个

动作对应的命令为Basic.Consume 或者Basic. Get) ，经过可能的解包处理得到原始的数据，
之后再进行业务处理逻辑。这个业务处理逻辑并不一定需要和接收消息的逻辑使用同一个线程。
消费者进程可以使用一个线程去接收消息，存入到内存中，比如使用Java 中的BlockingQueue 。
业务处理逻辑使用另一个线程从内存中读取数据，这样可以将应用进一步解稿，提高整个应用
的处理效率。

队列

Queue: 队列，是RabbitMQ 的内部对象，用于存储消息。参考图2- 1.队列可以用图2-3
表示。

RabbitMQ 中消息都只能存储在队列中，这一点和Katka 这种消息中间件相反。Katka 将消
息存储在topic (主题)这个逻辑层面，而相对应的队列逻辑只是topic 实际存储文件中的位移
标识。RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。
多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（Round-Robin ，即轮询)
给多个消费者进行处理，而不是每个消费者都收到所有的消息井处理，如图2-4 所示。

RabbitMQ 不支持队列层面的广播消费，如果需要广播消费，需要在其上进行二次开发，处理逻辑会变得异常复杂，同时也不建议这么做。

交换器、路由键、绑定

Exchange: 交换器。在图2-4 中我们暂时可以理解成生产者将消息投递到队列中，实际上
这个在RabbitMQ 中不会发生。真实情况是，生产者将消息发送到Exchange (交换器，通常也
可以用大写的"X" 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或
许会返回给生产者，或许直接丢弃。这里可以将RabbitMQ 中的交换器看作一个简单的实体，
更多的细节会在后面的章节中有所涉及。

RabbitMQ 中的交换器有四种类型，不同的类型有着不同的路由策略，这将在下一节的交换
器类型(Exchange Types) 中介绍。

RoutingKey: 路由键。生产者将消息发给交换器的时候， 一般会指定一个RoutingKey ，用
来指定这个消息的路由规则，而这个RoutingKey 需要与交换器类型和绑定键(BindingKey) 联
合使用才能最终生效。
在交换器类型和绑定键(BindingKey) 固定的情况下，生产者可以在发送消息给交换器时，
通过指定RoutingKey 来决定消息流向哪里。

Binding: 绑定。RabbitMQ 中通过绑定将交换器与队列关联起来，在绑定的时候一般会指

定一个绑定键( BindingKey ) ，这样RabbitMQ 就知道如何正确地将消息路由到队列了，如图2-6
所示。

生产者将消息发送给交换器时， 需要一个RoutingKey ， 当BindingKey 和RoutingKey 相匹
配时， 消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候， 这些绑定允许
使用相同的BindingKey。BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型， 比
如fanout 类型的交换器就会无视BindingKey ， 而是将消息路由到所有绑定到该交换器的队列中。

对于初学者来说， 交换器、路由键、绑定这几个概念理解起来会有点晦涩， 可以对照着代
码清单1-1 来加深理解。
沿用本章开头的比喻， 交换器相当于投递包裹的邮箱， RoutingKey 相当于填写在包裹上的
地址， BindingKey 相当于包裹的目的地， 当填写在包裹上的地址和实际想要投递的地址相匹配
时， 那么这个包裹就会被正确投递到目的地， 最后这个目的地的"主人"一一队列可以保留这
个包裹。如果填写的地址出错，邮递员不能正确投递到目的地， 包裹可能会回退给寄件人，也
有可能被丢弃。
有经验的读者可能会发现， 在某些情形下， RoutingKey 与BindingKey 可以看作同一个东西。
代码清单2-1 所展示的是代码清单1-1 中的部分代码:

以上代码声明了一个direct 类型的交换器(交换器的类型在下一节会详细讲述)，然后将交
换器和队列绑定起来。注意这里使用的字样是"ROUTING_阻y"，在本该使用BindingKey 的
channel .qu eueBind 方法中却和channe l.basicPublish 方法同样使用了RoutingKey ，
这样做的潜台词是:这里的RoutingKey 和BindingKey 是同一个东西。在direct 交换器类型下，
RoutingKey 和BindingKey 需要完全匹配才能使用，所以上面代码中采用了此种写法会显得方便
许多。

但是在topic 交换器类型下， RoutingKey 和BindingKey 之间需要做模糊匹配，两者并不是
相同的。
BindingKey 其实也属于路由键中的一种，官方解释为: the routing key to use for the binding。
可以翻译为:在绑定的时候使用的路由键。大多数时候，包括官方文档和RabbitMQ Java API
中都把BindingKey 和RoutingKey 看作RoutingKey ，为了避免混淆，可以这么理解:

• 在使用绑定的时候，其中需要的路由键是BindingKey 。涉及的客户端方法如:

channel.exchangeBind 、channel .queueBind ，对应的AMQP 命令(详情参见
2.2 节)为Exchange.Bind 、Queue.Bind 。

• 在发送消息的时候，其中需要的路由键是RoutingKey 。涉及的客户端方法如

channel .basicPublish ，对应的AMQP 命令为Basic.Publish 。

由于某些历史的原因，包括现存能搜集到的资料显示:大多数情况下习惯性地将BindingKey
写成RoutingKey ，尤其是在使用direct 类型的交换器的时候。本文后面的篇幅中也会将两者合
称为路由键，读者需要注意区分其中的不同，可以根据上面的辨别方法进行有效的区分。

交换器类型

RabbitMQ 常用的交换器类型有fanout 、direct、topic 、headers 这四种。AMQP 协议里还提
到另外两种类型: System 和自定义，这里不予描述。对于这四种类型下面一一阐述。

fanout
它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

direct
direct 类型的交换器路由规则也很简单，它会把消息路由到那些BindingKey 和RoutingKey
完全匹配的队列中。

以图2-7 为例，交换器的类型为direct，如果我们发送一条消息，并在发送消息的时候设置
路由键为" warning" ，则消息会路由到Queuel 和Queue2 ，对应的示例代码如下:
channel.basicPublish(EXCHANGE_NAME, "warning" ,
MessageProperties .PERSISTENT TEXT PLAIN,
message.getBytes()) ;

如果在发送消息的时候设置路由键为" info" 或者"debug" ，消息只会路由到Queue2 。如
果以其他的路由键发送消息，则消息不会路由到这两个队列中。

topic
前面讲到direct 类型的交换器路由规则是完全匹配BindingKey 和RoutingKey ，但是这种严
格的匹配方式在很多情况下不能满足实际业务的需求。topic 类型的交换器在匹配规则上进行了
扩展，它与direct 类型的交换器相似，也是将消息路由到BindingKey 和RoutingKey 相匹配的队
列中，但这里的匹配规则有些不同，它约定:

• RoutingKey 为一个点号". "分隔的字符串(被点号" ."分隔开的每一段独立的字符

串称为一个单词)，如"com.rabbitmq.client"，"java,util.concurrent","com.hidden,client";

• BindingKey 和RoutingKey 一样也是点号" ."分隔的字符串;
• BindingKey 中可以存在两种特殊字符串"*"和"#"，用于做模糊匹配，其中"#"用

  于匹配一个单词，'#"用于匹配多规格单词(可以是零个)。
  以图2-8 中的配置为例:

• 路由键为" com.rabbitmq.client" 的消息会同时路由到Queuel 和Queue2;
• 路由键为" com.hidden.client" 的消息只会路由到Queue2 中:
• 路由键为" com.hidden.demo" 的消息只会路由到Queue2 中:
• 路由键为"java.rabbitmq.demo" 的消息只会路由到Queuel 中:

• 路由键为" java.util..concurrent" 的消息将会被丢弃或者返回给生产者(需要设置
  mandatory 参数) ，因为它没有匹配任何路由键。

headers
headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中
的headers 属性进行匹配。在绑定队列和交换器时制定一组键值对， 当发送消息到交换器时，
RabbitMQ 会获取到该消息的headers (也是一个键值对的形式) ，对比其中的键值对是否完全
匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由
到该队列。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。