RabbitMQ 整体上是 一个生产者与消费者模型，主要负责接收、存储和转发消息。可以把消息传递的过程想象成:当你将一个包裹送到邮局，邮局会暂存并最终将邮件通过邮递员送到收件人的手上， RabbitMQ 就好比邮局、邮箱和邮递员组成的一个系统。从计算机术语层面来说，RabbitMQ 模型更像是一种交换机模型。
生产者和消费者
Producer: 生产者，就是投递消息的 一方。
消息一般可以包含两个部分:消息体和标签（Label) 。消息体 也可以称之为 payload ，在实际应用中，消息体 一般是一个带有业务逻辑结构的数据，比如一个 JSON 字符串。当然可以进一步对这个消息体进行序列化操作。 消息的标签，用来表述这条消息 比如 个交换器的名称和 个路由键 生产者把消息交由 RabbitMQ，RabbitMQ 之后会根据标签把消息发送给感兴趣 消费者 Consumer。
Consumer: 消费者 就是接收消息的 一方。
消费者连接到 RabbitMQ 服务器，并订阅到队列上 当消费者消费 条消息时 只是消费消息的消息体 yload 在消息路由的过程中 消息的标签会丢弃 存入到队列中的消息只有消息体，消费者也只会消费到消息体 也就不知道消息的生产者是谁，当然消费者也不知道。
Broker: 消息中间件的服务节点
RabbitMQ 来说， RabbitMQ Broker 简单 看作 RabbitMQ 服务节点或者 RabbitMQ 服务实 数情况RabbitMQ Broker 看作 RabbitMQ服务器。
队列
Queue: 队列，是 RabbitMQ 的内部对象，用 于存储消息。
RabbitMQ 中消息都只能存储在队列中，这 一点 Katka 这种消息中间件相反 Katka 将消息存储在 topic (主题)这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移标识。 RabbitMQ 的生产者生产消息井最终技递到队列中，消费者可以从队列中获取消息并消费。
多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊 (Round-Robin ，即轮询)给多个消费者进行处理，而不是每个消费者都收到所有的消息井处理.
RabbitMQ 不支持队列 层面的广播消费，如果需要广播消费，需要在其上进行 次开发，处理逻辑会变得异常复杂，同时也不建议这么做。
交换器 、路由键、绑定
Exchange: 交换器
真实情况是，生产者将消息发送到 Exchange (交换器，通常也可以用大写的 "X" 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃
RabbitMQ 中的 交换器有四种类型，不同的类型有着不 同的路由策略，这将在下 一节 的交换
器类型 (Exchange Types) 中介绍
RoutingKey: 路由键 。生产者将消息发给交换器 的时候， 一般会 指定 一个 RoutingKey ，用
来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键 (BindingKey)
合使用才能最终生效。
在交换器类型和绑定键 (BindingKey) 固定的情况下，生产者可以在发送消息给交换器时，
通过指定 RoutingKey 来决定消息流向哪里。
Binding: 绑定 Rabbi tM 中通过绑定将交换器与队列关联起来，在绑定的时候 一般会指定一 绑定键 BindingKey ，这样 RabbitMQ 就知 何正确 将消息路由 队列了。
生产者将消息发送给交换器 时， 需要一 Rout ngKey BindingKey RoutingKey 相匹
时， 消息会被路由 对应 中。在绑定多个队列到同一个交换器的时候 这些绑定允许
使用 同的 BindingKey 0 BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型
fanout 类型 器就会无 BindingKey 是将消息路由到所有绑定到该交换器的队列中。
在 direct 交换器类型下，RoutingKey BindingKey 需要完全匹配才能使用。topic 交换器类型下， RoutingKey BindingKey 之间 需要做模糊匹配，两者并不是相同的。
交换器类型
RabbitMQ 常用的交换器类型有 fanout direct topic headers 这四种 AMQP 协议里还提到另外两种类型: System 和自定义，这里不予描述。对于这四种类型下面一一阐述。
fanout
它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
direct
direct 类型的交换器路由规则也很简单，它 会把消息路由到那些 BindingKey RoutingKey
完全匹配的队列中。
topic
前面讲到 direct 类型的交换器路由规则是完全匹配 BindingKey RoutingKey ，但是这种严
格的匹配方式在很多情况下不能满足实际业务的需求。 ωpic 类型的交换器在匹配规则上进行了
扩展，它与 direct 类型的交换器相似，也是将消息路由到 BindingKey RoutingKey 相匹配的队
列中，但这里的匹配规则有些不同，它约定:
RoutingKey 为一个点号" "分隔的字符串(被点号" "分隔开的每 段独立的字符
串称为 个单词 ) ，如 "com.rabbiq.client"
BindingKey RoutingKey 样也是点号" "分隔的字符串;
BindingKey 中可以存在两种特殊 字符串"*"和"#"，用于做模糊匹配，其中"#"用于匹配 个单词，吁"用于匹配多规格单词(可以是零个)。
headers
headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中
headers 属性进行匹配。在绑定队列和交换器时制定一组键值对 当发送消息到交换器时，
Rabbi tM 会获取到该消息的 headers (也是一个键值对的形式) ，对比其中的键值对 是否完全
匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由
到该队列 headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。
