0


RabbitMQ

RabbitMQ快速入门

RabbitMQ是由erlang语言开发,基于AMQP(Advanced Message Queue 高级消息队列协议)协议实现的消息队列

RabbitMQ的工作原理

组成部分说明:

Broker:消息队列服务进程,此进程包括两个部分:Exchange和Queue

Exchange:消息队列交换机,按一定的规则将消息路由转发到某个队列,对消息进行过虑。

Queue:消息队列,存储消息的队列,消息到达队列并转发给指定的

Producer:消息生产者,即生产方客户端,生产方客户端将消息发送

Consumer:消息消费者,即消费方客户端,接收MQ转发的消息。

生产者发送消息流程:

1、生产者和Broker建立TCP连接。

2、生产者和Broker建立通道。

3、生产者通过通道消息发送给Broker,由Exchange将消息进行转发。

4、Exchange将消息转发到指定的Queue(队列)

消费者接收消息流程:

1、消费者和Broker建立TCP连接

2、消费者和Broker建立通道

3、消费者监听指定的Queue(队列)

4、当有消息到达Queue时Broker默认将消息推送给消费者。

5、消费者接收到消息。

6、ack回复

消息确认机制(ACK)

当消费者获取消息后,会向RabbitMQ发送回执ACK,告知消息已经被接收。删除队列中的消息

回执ACK分两种情况:

  • 自动ACK:消息一旦被接收,消费者自动发送ACK(用作消息不太重要场景)
  • 手动ACK:消息接收后,不会发送ACK,需要手动调用(用作消息很重要, 不可丢失场景)

六种消息模型

①基本消息模型:

  • P:生产者,也就是要发送消息的程序
  • C:消费者:消息的接受者,会一直等待消息到来。
  • queue:消息队列,图中红色部分。可以缓存消息;生产者向其中投递消息,消费者从其中取出消息。

②work消息模型

两个消费端共同消费同一个队列中的消息,但是一个消息只能被一个消费者获取。这个消息模型在Web应用程序中特别有用,可以处理短的HTTP请求窗口中无法处理复杂的任务。

生产者会将消息平均分发给两个消费端,但是当其中一个消费端处理其他工作时, 我们正确做法是将消息分发给空闲的消费端, 需要设置一个参数 prefetchCount = 1。 注意, 这个参数只有在手动ack下才生效

订阅模型分类

1、一个生产者多个消费者

2、每个消费者都有一个自己的队列

3、生产者没有将消息直接发送给队列,而是发送给exchange(交换机、转发器)

4、每个队列都需要绑定到交换机上

5、生产者发送的消息,经过交换机到达队列,实现一个消息被多个消费者消费

X(Exchanges):交换机一方面:接收生产者发送的消息。另一方面:知道如何处理消息,例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作,取决于Exchange的类型。

Exchange类型有以下几种:

Fanout:广播,将消息交给所有绑定到交换机的队列

Direct:定向,把消息交给符合指定routing key 的队列

Topic:通配符,把消息交给符合routing pattern(路由模式) 的队列

Header:header模式与routing不同的地方在于,header模式取消routingkey,使用header中的 key/value(键值对)匹配队列。

Header模式不展开了,感兴趣可以参考这篇文章 RabbitMQ学习之Headers交换类型(java)_header类型的mq 是不是 没有消费者也没事-CSDN博客

Exchange(交换机)只负责转发消息,不具备存储消息的能力,如果没有任何队列与Exchange绑定,或者没有符合路由规则的队列,那么消息会丢失!

Publish/subscribe(交换机类型:Fanout,也称为广播

图中的蓝色X代表Exchange(交换机)

  • 1) 声明Exchange,不再声明Queue
  • 2) 发送消息到Exchange,不再发送到Queue
  • 3) 队列需要绑定到交换机, 交换机会发送消息给所有绑定他的队列

④Routing 路由模型(交换机类型:direct)

P:生产者,向Exchange发送消息,发送消息时,会指定一个routing key。

X:Exchange(交换机),接收生产者的消息,然后把消息递交给 与routing key完全匹配的队列

C1:消费者,其所在队列指定了需要routing key 为 error 的消息

C2:消费者,其所在队列指定了需要routing key 为 info、error、warning 的消息

⑤Topics 通配符模式(交换机类型:topics)

每个消费者监听自己的队列,并且设置带统配符的routingkey,生产者将消息发给broker,由交换机根据routingkey来转发消息到指定的队列。

Routingkey一般都是有一个或者多个单词组成,多个单词之间以“.”分割,例如:inform.sms

通配符规则:

#:匹配一个或多个词

*:匹配不多不少恰好1个词

举例:

audit.#:能够匹配audit.irs.corporate 或者 audit.irs

audit.*:只能匹配audit.irs

⑥RPC

RPC是指远程过程调用,也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。

Callback queue 回调队列客户端向服务器发送请求,服务器端处理请求后,将其处理结果保存在一个存储体中。而客户端为了获得处理结果,那么客户在向服务器发送请求时,同时发送一个回调队列地址reply_to。

Correlation id 关联标识,客户端可能会发送多个请求给服务器,当服务器处理完后,客户端无法辨别在回调队列中的响应具体和那个请求时对应的。为了处理这种情况,客户端在发送每个请求时,同时会附带一个独有correlation_id属性,这样客户端在回调队列中根据correlation_id字段的值就可以分辨此响应属于哪个请求。

流程说明

  • 当客户端启动的时候,它创建一个匿名独享的回调队列。
  • 在 RPC 请求中,客户端发送带有两个属性的消息:一个是设置回调队列的 reply_to 属性,另一个是设置唯一值的 correlation_id 属性。
  • 将请求发送到一个 rpc_queue 队列中。
  • 服务器等待请求发送到这个队列中来。当请求出现的时候,它执行他的工作并且将带有执行结果的消息发送给 reply_to 字段指定的队列。
  • 客户端等待回调队列里的数据。当有消息出现的时候,它会检查 correlation_id 属性。如果此属性的值与请求匹配,将它返回给应用

本文转载自: https://blog.csdn.net/Small_white_528/article/details/142460006
版权归原作者 Small_white_wall 所有, 如有侵权,请联系我们删除。

“RabbitMQ”的评论:

还没有评论