rabbitmq架构图

image.png

架构拆解

Publisher 生产者，就是投递消息的一方。

    生产者创建消息，然后发布到 RabbitMQ 。消息一般可以包含两个部分：消息体和标签
    消息体也可以称之为 payload ，在实际应用中，消息体一般是一个带有业务逻辑结构的数据，比如一个 JSON 字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签用来表述这条消息，比如一个交换器的名称和一个路由键。生产者把消息交由 RabbitMQ,RabbitMQ 之后会根据标签把消息发送给感兴趣的消费者（ Consumer ）。

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

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

Broker ：消息中间件的服务节点

    对于 RabbitMQ 来说， RabbitMQ Broker 可以简单地看作一个 RabbitMQ 服务节点。

消息队列的运转过程

image.png

Queue 队列

    多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（Round-Robin ，即轮询）
给多个消费者进行处理，而不是每个消费者都收到所有的消息井处理，RabbitMQ 不支持队列层面的广播消费。

Exchange ：交换器

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

RoutingKey ：路由键

    生产者将消息发给交换器的时候， 一般会指定一个RoutingKey ，用来指定这个消息的路由规则，而这个 Routing Key 需要与交换器类型和绑定键（ BindingKey ）联合使用才能最终生效。

Binding ：绑定

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

BindingKey其实也属于路由键的一种
官方文档和 RabbitMQ Java API 中都把 BindingKey 和RoutingKey看作 RoutingKey

Connection ：TCP连接

    无论是生产者还是消费者，都需要和RabbitMQ Broker建立连接，这个连接就是一条TCP连接，也就是Connection。一旦TCP连接建立起来，客户端可以紧接着创建一个AMQP信道（Channel）。

Channel ：信道

    信道是建立在 Connection 之上的虚拟连接，

image.png

问题：

我们完全可以直接使用 Connection 就能完成信道的工作，为什么还要引入信道呢？

    对于操作系统而言，建立和销毁 TCP 连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。 RabbitMQ 采用类似 NIO (Non-blocking IO）的做法，选择 TCP 连接复用，不仅可以减少性能开销，同时也便于管理