RabbitMQ 的整体模型架构如图所示
image.png

生产者和消费者

Producer: 生产者，就是投递消息的一方。
生产者创建消息，发布到RabbitMQ中。消息一般可以包含2个部分：消息体(payload) 和 标签(Labels)。
消息体一般是一个带有业务逻辑结构的数据。
消息的标签用来表述这条消息，比如一个交换器的名称和一个路由键。生产者把消息交由 RabbitMQ，RabbitMQ之后会根据标签把消息发送给感兴趣的消费者(Consumer)。

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

Broker：消息中间件的服务节点。
对于 RabbitMQ 来说，一个RabbitMQ Broker可以简单地看作一个RabbitMQ 服务节点，或者RabbitMQ服务实例。大多数情况下也可以将一个 RabbitMQ Broker看作一台RabbitMQ 服务器。
image.png

队列

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

交换器、路由键、绑定

Exchange: 交换器

生产者将消息发送到 Exchange (交换器，通常也 可以用大写的 “X” 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃。

RoutingKey: 路由键

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

Binding:绑定

RabbitMQ 中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键 ( BindingKey ) ，这样 RabbitMQ 就知道如何正确地将消息路由 到 队列了

交换器类型

fanout

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

direcrt

它会把消息路由到那些 BindingKey 和 RoutingKey 完全匹配的队列中。

topic

  • RoutingKey 为一个符号“.”分隔的字符串(被点号“.”分隔开的每一段独立的字符串称为一个单词。)
  • BindingKey 和 RoutingKey 一样也是点号”.”分隔的字符串;
  • BindingKey 中可以存在两种特殊字符串“”和“#”，用于做模糊匹配，其中“”用于匹配一个单词，“#”用于匹配多规格单词（可以是零个）。

    headers

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