RabbitMQ入门介绍

最新推荐文章于 2024-05-08 04:33:01 发布

阳光_你好

最新推荐文章于 2024-05-08 04:33:01 发布

阅读量91

点赞数

文章标签： rabbitmq

本文链接：https://blog.csdn.net/weixin_45805339/article/details/120549426

版权

RabbitMQ是一个是一个生产者与消费者模型，主要负责接收、存储和转发消息。整体模型架构入下图：
在这里插入图片描述

生产者和消费者

Producer: 生产者，就是投递消息的一方。
生产者创建消息，然后发布到 RabbitMQ 中。消息般可以包含个部分:消息体和标签（Label) 。消息体也可以称之为 payload ，在实际应用中，消息体般是一个带有业务逻辑结构的数据，比如一个 JSON 字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签用来表述这条消息比如个交换器的名称和个路由键生产者把消息交由 RabbitMQ
RabbitMQ 之后会根据标签把消息发送给感兴趣消费者（Consumer）。
Consumer: 消费者就是接收消息的一方。
消费者连接到 RabbitMQ 服务器，并订阅到队列上。当消费者消费一条消息时，只是消费消息的消息体（payload）在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费到消息体，也就不知道消息的生产者是谁，当然消费者也不知道。
Broker: 消息中间件的服务节点。
对于RabbitMQ 来说，一个RabbitMQ Broker可以简单地看作一个RabbitMQ 服务节点，或者 RabbitMQ 服务实例。大多数情况下也可以将一个RabbitMQ Broker 看作一台RabbitMQ服务器。

下图展示了生产者将消息存入 RabbitMQ Broker，以及消费者从Broker中消费数据的整个流程。
在这里插入图片描述
首先生产者将业务方数据进行可能的包装，之后封装成消息，发送（AMQP 协议里这个动作对应的命令为 Basic.Publish）到Broker中。消费者订阅并接收消息（AMQP 协议里这个动作对应的命令为Basic.Co sume 或者 Basic.Get) ，经过可能的解包处理得到原始的数据，
之后再进行业务处理逻辑。这个业务处理逻辑并不一定需要和接收消息的逻辑使用同一个线程。消费者进程可以使用一个线程去接收消息，存入到内存中，比如使用 Java 中的 BlockingQueue。业务处理逻辑使用另一个线程从内存中读取数据，这样可以将应用进一步解耦，提高整个应用的处理效率。

队列

Queue: 队列，是 RabbitMQ 的内部对象，用于存储消息。
RabbitMQ 中消息都只能存储在队列中，这一点和Kafka 这种消息中间件相反。Kafka 将消息存储在topic（主题）这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移标识。RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。
多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（Round-Robin ，即轮询)给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。如下图：
在这里插入图片描述
RabbitMQ 不支持队列层面的广播消费，如果需要广播消费，需要在其上进行二次开发，处理逻辑会变得异常复杂，同时也不建议这么做。

交换器路由键绑定

Exchange: 交换器。
生产者将消息发送到 Exchange (交换器，通常也可以用大写的 “X” 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃。这里可以将 RabbitMQ 中的交换器看作一个简单的实体。如下图：
在这里插入图片描述
交换器类型
RabbitMQ常用的交换器类型有fanout、direct、topic、headers这四种。AMQP协议里还提到另外两种类型：System和自定义。
RabbitMQ 中的交换器有四种类型，不同的类型有着不同的路由策略。
fanout
他会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
direct
会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中。
如果我们发送一条消息，并在发送消息的时候设置路由键为"warning" ，则消息会路由到 Queue1和Queue2 ，对应的示例代码如下:
在这里插入图片描述
如果在发送消息的时候设置路由键为" info" 或者 “debug” ，消息只会路由到 Queue2。如果以其他的路由键发送消息，则消息不会路由到这两个队列中。
topic
前面讲到 direct 类型的交换器路由规则是完全匹配 BindingKey和RoutingKey ，但是这种严格的匹配方式在很多情况下不能满足实际业务的需求。 topic 类型的交换器在匹配规则上进行了扩展，它与 direct 类型的交换器相似，也是将消息路由到 BindingKey RoutingKey 相匹配的队列中，但这里的匹配规则有些不同，它约定:

RoutingKey 为一个点号" .“分隔的字符串(被点号” ."分隔开的每一段独立的字符串称为一个单词 )，如 “com.rabbitmq.client”、“java.util.concurrrent”、 “com.hidden.client”；
BindingKey和RoutingKey一样也是点号"."分隔的字符串;
BindingKey 中可以存在两种特殊字符串"*“和”#"，用于做模糊匹配，其中"#“用于匹配一个单词，”#"用于匹配多规格单词(可以是零个)。
以下图为例：
路由键为" com.rabbitmq.client" 的消息会同时路由到 Queue1和Queue2;
路由键为"com.hidden.client" 的消息只会路由到 Queue2 中:
路由键为" com.hidden.demo" 的消息只会路由到 Queue2 中:
路由键为 “java.rabbitmq.demo” 的消息只会路由到 Queuel1中:
路由键为"java.util. concurrent" 的消息将会被丢弃或者返回给生产者(需要设置mandatory 参数) ，因为它没有匹配任何路由键。
headers
headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的headers 属性进行匹配。在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，RabbitMQ会获取到该消息的 headers (也是一个键值对的形式) ，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列 headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。

RoutingKey: 路由键。
生产者将消息发给交换器的时候，一般会指定一个 RoutingKey ，用来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键 (BindingKey)联合使用才能最终生效。
在交换器类型和绑定键 (BindingKey) 固定的情况下，生产者可以在发送消息给交换器时，通过指定RoutingKey来决定消息流向哪里。
Binding: 绑定。
RabbitMQ中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键（BindingKey ），这样 RabbitMQ 就知到如何正确的将消息路由到队列了，如下图：
在这里插入图片描述
生产者将消息发送给交换器时，需要一个RoutingKey，当BindingKey和RoutingKey相匹配时，消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的BindingKey。BindingKey并不是在所有的情况下都生效，它依赖于交换器类型，比如fanout类型的交换器就会无视BindingKey，而是将消息路由到所有绑定到该交换器的队列中。
交换器相当于投递包裹的邮箱，RoutingKey相当于填写在包裹上的地址， BindingKey 当于包裹目的地，当填写在包裹上的地址和实际想要投递的地址相匹配时，那么这个包裹就会被正确投递到目的地，最后这个目地的地的"主人"一一队列可以保留这包裹。如果填写目的地址出错，邮递员不能正确投递到目的地，包裹可能会回退给寄件人，也有可能被丢弃。在某些情形下 RoutingKey与BindingKe 可以看作同一个东西。