RabbitMQ 整体上是 一个生产者与消费者模型，主要负责接收、存储和转发消息。可以把消 息传递的过程想象成:当你将一个包裹送到邮局，邮局会暂存并最终将邮件通过邮递员送到收 件人的手上， RabbitMQ 就好比由邮局、邮箱和邮递员组成的一个系统。从计算机术语层面来说， RabbitMQ 模型更像是一种交换机模型 。
RabbitMQ 的整体模型架构如图 
1、生产者和消费者
Producer: 生产者，就是投递消息的 一方。
生产者创建消息，然后发布到 RabbitMQ 中。消息一般可以包含 2 个部分:消息体和标签 CLabel)。消息体也可以称之为 payload，在实际应用中，消 息体一般是一个带有业务逻辑结构 的数据，比如一个 JSON 字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签用来表述这条消息 ， 比如 一个交换器的名称和 一个路由键 。 生产者把消息交由 RabbitMQ，RabbitMQ 之后会根据标签把消息发送给感兴趣 的消费者 CConsumer)。
Consumer: 消费者 ， 就是接收消息的 一方。
消费者连接到 RabbitMQ 服务器，并订阅到队列上 。 当消费者消费 一 条消息时 ， 只是消费 消息的消息体 Cpayload)。 在消息路由的过程中 ， 消息的标签会丢弃 ， 存入到队列中的消息只 有消息体，消费者也只会消费到消息体 ， 也就不知道消息的生产者是谁，当然消费者也不 需要 知道。
Broker: 消息中间件的服务节点 。
对于 RabbitMQ来说， 一个 RabbitMQBroker可以简单地看作一个 RabbitMQ服务节点， 或者 RabbitMQ服务实例。 大多数情况下也可以将一个 RabbitMQ Broker看作一台 RabbitMQ 服务器 。
2、队列
Queue: 队列，是 RabbitMQ 的内部对象，用 于存储消息。
RabbitMQ 中消息都只能存储在队列中，这 一点 和 Katka 这种消息中间件相反 。 Katka 将消 息存储在 topic C主题)这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移 标识。 RabbitMQ 的生产者生产消息井最终技递到队列中，消费者可以从队列中获取消息并消费 。
多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊 CRound-Robin，即轮询) 给多个消费者进行处理，而不是每个消费者都收到所有的消息井处理，如图 所示。
RabbitMQ 不支持队列 层面的广播消费，如果需要广播消费，需要在其上进行 二 次开发，处理逻辑会变得异常复杂。
3、交换器、路由键、绑定
Exchange: 交换器。在图 2-4 中我们暂时可以理解成生产者将消息投递到队列中，实际上 这个在 RabbitMQ 中不会发生。真实情况是，生产者将消息发送到 Exchange (交换器，通常也 可以用大写的 “X” 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或 许会返回给生产者，或许直接丢弃。这里可以将 RabbitMQ 中的交换器看作一个简单的实体， 更多的细节会在后面的章节中有所涉及。交换器的具体示意图如图 所示。
RabbitMQ 中的交换器有四种类型（下文有说明），不同的类型有着不同的路由策略。
RoutingKey: 路由键 。生产者将消息发给交换器 的时候， 一般会 指定 一个 RoutingKey，用 来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键 (BindingKey) 联 合使用才能最终生效。
在交换器类型和绑定键 (BindingKey) 固定的情况下，生产者可以在发送消息给交换器时， 通过指定RoutingKey来决定消息流向哪里。
Binding: 绑定 。 RabbitMQ 中通过绑定将交换器与队列关联起来，在绑定的时候 一般会指定一个绑定键 (BindingKey)，这样 RabbitMQ就知道如何正确地将消息路由到队列了，如图所示。
生产者将消息发送给交换器时， 需要一个 RoutingKey， 当 BindingKey和 RoutingKey相匹 配时， 消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候， 这些绑定允许 使用 相 同的 BindingKey0 BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型 ， 比 如 fanout类型的交换器就会无视 BindingKey，而是将消息路由到所有绑定到该交换器的队列中 。
注：在使用绑定的时候，其中需要的路由键是 BindingKey，在发送消息的时候，其中需要的路由键是 RoutingKey。 后面会有文章介绍如何使用（基于 springboot 2.0）
4、交换器类型
RabbitMQ 常用的交换器类型有 fanout、 direct、 topic、 headers 这四种 。 AMQP 协议里还提
到另外两种类型: System 和自定义，这里不予描述。对于这四种类型下面一一阐述。
fanout
它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
direct
direct类型的交换器路由规则也很简单，它会把消息路由到那些 BindingKey和 RoutingKey 完全匹配的队列中。
以下图为例，交换器的类型为 direct，如果我们发送一条消息，并在发送消息的时候设置 路由键为" warning"，则消息 会路由到 Queuel 和 Queue2
如果在发送消息的时候设置路由键为" info" 或者 “debug”，消息 只会路由到 Queue2。 如
果以其他的路由键发送消息，则消息不会路由到这两个队列中。
topic
前面讲到 direct类型的交换器路由规则是完全匹配 BindingKey 和 RoutingKey，但是这种严 格的匹配方式在很多情况下不能满足实际业务的需求。 topic类型的交换器在匹配规则上进行了扩展，它与 direct类型的交换器相似，也是将消息路由到 BindingKey 和 RoutingKey 相匹配的队列中，但这里的匹配规则有些不同，它约定:
- RoutingKey 为一个点号".“分隔的字符串(被点号”.“分隔开的每一段独立的字符串称为一个单词 )，如"com.rabbitmq.client”、“com.hidden.client”、
- BindingKey 和 RoutingKey 一样也是点号". "分隔的字符串;
- BindingKey 中可以存在两种特殊 字符串"*“和”#"，用于做模糊匹配，其中"#“用 于匹配一个单词，”#"用于匹配多规格单词(可以是零个)。
以下图中的配置为例:
- 路由键为" 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 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。
5、RabbitMQ 运转流程
生产者发送消息过程：
(1)生产者连接到 RabbitMQBroker， 建立一个连接(Connection)，开启一个信道 (Channel)
(2) 生产者声明一个交换器 ，并设置相关属性，比如 交换机类型、是否持久化等
(3)生产者声明 一个队列井设置相关属性，比如是否排他、是否持久化、是否自动删除等
(4) 生产者通过路由键将交换器和队列绑定起来
(5) 生产者发送消息至 RabbitMQ Broker，其中包含路由键、交换器等信息
(6) 相应的交换器根据接收到的路由键查找相匹配的队列 。
(7) 如果找到 ，则将从 生产者发送过来的消息存入相应的队列中。
(8) 如果没有找到 ，则根据生产者配置的属性选择丢弃还是回退给生产者
(9) 关闭信道。
(10) 关闭连接。
消费者接收消息的过程:
(1)消费者连接到 RabbitMQBroker，建立一个连接(Connection)，开启一个信道(Channel)。
(2)消费者向 RabbitMQBroker请求消费相应队列中的消息，可能会设置相应的回调函数， 以及做一些准备工作
(3)等待 RabbitMQ Broker 回应并投递相应队列中的消息，
(4) 消费者确认 (ack) 接收到的消息 。
(5) RabbitMQ 从队列中删除相应己经被确认的消息 。
(6) 关闭信道。
(7) 关闭连接。
案例地址：https://gitee.com/huangfubin/blog-demo/tree/master/rabbitmq-demo/rabbitmq-sample
扫一扫
973
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
