.Net RabbitMQ实战指南——RabbitMQ相关概念介绍

什么是消息中间件

消息(Message)是指在应用间传送的数据。消息可以非常简单,比如只包含文本字符串、JSON等,也可以很复杂,比如内嵌对象。

消息队列中间件(Message Queue Middleware,简称为MQ)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信。

面向消息的中间件(简称为MOM,Message Oriented Middleware)提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送,即应用程序彼此不直接通信,而是与作为中介的消息中间件通信。消息中间件提供了有保证的消息发送,应用程序开发人员无须了解远程过程调用(RPC)和网络通信协议的细节。

举例说明,应用程序A与应用程序B通过使用消息中间件的应用程序编程接口(API,Application Program Interface)发送消息来进行通信。

消息中间件的作用

消息中间件凭借其独到的特性,在不同的应用场景下可以展现不同的作用。

解耦:消息中间件在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,这允许你独立地扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束即可。

冗余(存储):消息中间件可以把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。在把一个消息从消息中间件中删除之前,需要你的处理系统明确地指出该消息已经被处理完成,从而确保你的数据被安全地保存直到你使用完毕。

扩展性:因为消息中间件解耦了应用的处理过程,所以提高消息入队和处理的效率是很容易的,只要另外增加处理过程即可,不需要改变代码,也不需要调节参数。

削峰:在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。使用消息中间件能够使关键组件支撑突发访问压力,不会因为突发的超负荷请求而完全崩溃。

可恢复性:消息中间件降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入消息中间件中的消息仍然可以在系统恢复后进行处理。

顺序保证:在大多数使用场景下,数据处理的顺序很重要,大部分消息中间件支持一定程度上的顺序性。

缓冲:在任何重要的系统中,都会存在需要不同处理时间的元素。消息中间件通过一个缓冲层来帮助任务最高效率地执行,写入消息中间件的处理会尽可能快速。该缓冲层有助于控制和优化数据流经过系统的速度。

异步通信:在很多时候应用不想也不需要立即处理消息。消息中间件提供了异步处理机制,允许应用把一些消息放入消息中间件中,但并不立即处理它,在之后需要的时候再慢慢处理。

RabbitMQ相关介绍

RabbitMQ整体上是一个生产者与消费者模型,主要负责接收、存储和转发消息。

RabbitMQ的整体模型架构如图

 

Producer:生产者

生产者创建消息,然后发布到RabbitMQ中。消息一般可以包含2个部分:消息体和标签(Label)。消息体也可以称之为payload,在实际应用中,消息体一般是一个带有业务逻辑结构的数据,比如一个JSON字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签用来表述这条消息,比如一个交换器的名称和一个路由键。

Consumer:消费者

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

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

对于RabbitMQ来说,一个RabbitMQ Broker可以简单地看作一个RabbitMQ服务节点,或者RabbitMQ服务实例。大多数情况下也可以将一个RabbitMQ Broker看作一台RabbitMQ服务器。

消息队列的运转过程如图

 

Queue:队列,是RabbitMQ的内部对象,用于存储消息

RabbitMQ中消息都只能存储在队列中,多个消费者可以订阅同一个队列,这时队列中的消息会被平均分摊(Round-Robin,即轮询)给多个消费者进行处理,而不是每个消费者都收到所有的消息并处理,如图

 

Exchange:交换器

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

 

RabbitMQ常用的交换器类型有fanout、direct、topic、headers四种

fanout

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

direct

把消息路由到那些BindingKey和RoutingKey完全匹配的队列中。如图,交换器的类型为direct,如果我们发送一条消息,并在发送消息的时候设置路由键为“warning”,则消息会路由到Queue1和Queue2

topic

topic类型的交换器在匹配规则上进行了扩展,它与direct类型的交换器相似,也是将消息路由到BindingKey和RoutingKey相匹配的队列中,不同的是topic支持模糊匹配。BindingKey中可以存在两种特殊字符串“*”和“#”,用于做模糊匹配,其中“*”用于匹配一个单词,“#”用于匹配多个单词(可以是零个)。

●路由键为“com.rabbitmq.client”的消息会同时路由到Queue1和Queue2;

●路由键为“com.hidden.client”的消息只会路由到Queue2中;

●路由键为“com.hidden.demo”的消息只会路由到Queue2中;

●路由键为“java.rabbitmq.demo”的消息只会路由到Queue1中;

●路由键为“java.util.concurrent”的消息将会被丢弃或者返回给生产者(需要设置mandatory参数),因为它没有匹配任何路由键。

headers

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

RoutingKey:路由键

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

Binding:绑定

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

生产者将消息发送给交换器时,需要一个RoutingKey,当BindingKey和RoutingKey相匹配时,消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候,这些绑定允许使用相同的BindingKey。BindingKey并不是在所有的情况下都生效,它依赖于交换器类型,比如fanout类型的交换器就会无视BindingKey,而是将消息路由到所有绑定到该交换器的队列中。

RabbitMQ运转流程

生产者发送消息的过程

(1)生产者连接到RabbitMQ Broker,建立一个连接(Connection),开启一个信道(Channel)。

(2)生产者声明一个交换器,并设置相关属性,比如交换机类型、是否持久化等。

(3)生产者声明一个队列并设置相关属性,比如是否排他、是否持久化、是否自动删除等。

(4)生产者通过路由键将交换器和队列绑定起来。

(5)生产者发送消息至RabbitMQ Broker,其中包含路由键、交换器等信息。

(6)相应的交换器根据接收到的路由键查找相匹配的队列。

(7)如果找到,则将从生产者发送过来的消息存入相应的队列中。

(8)如果没有找到,则根据生产者配置的属性选择丢弃还是回退给生产者。

(9)关闭信道。

(10)关闭连接。

消费者接收消息的过程

(1)消费者连接到RabbitMQ Broker,建立一个连接(Connection),开启一个信道(Channel)。

(2)消费者向RabbitMQ Broker请求消费相应队列中的消息,可能会设置相应的回调函数,以及做一些准备工作。

(3)等待RabbitMQ Broker回应并投递相应队列中的消息,消费者接收消息。

(4)消费者确认(ack)接收到的消息。

(5)RabbitMQ从队列中删除相应已经被确认的消息。

(6)关闭信道。

(7)关闭连接。

无论是生产者还是消费者,都需要和RabbitMQ Broker建立连接,这个连接是一条TCP连接,也就是Connection。一旦TCP连接建立起来,客户端紧接着可以创建一个AMQP信道(Channel),每个信道都会被指派一个唯一的ID。信道是建立在Connection之上的虚拟连接,RabbitMQ处理的每条AMQP指令都是通过信道完成的。

 

 为什么要引入信道?

一个应用程序有很多个线程需要从RabbitMQ中消费消息或者生产消息,建立很多个Connection,也就是多个TCP连接,建立和销毁TCP连接是非常昂贵的开销。RabbitMQ采用类似NIO(Non-blocking I/O)的做法,选择TCP连接复用,不仅减少性能开销,同时也便于管理。每个线程把持一个信道,信道复用了Connection的TCP连接。当每个信道的流量不是很大时,复用单一的Connection可以在产生性能瓶颈的情况下有效地节省TCP连接资源。但是当信道的流量很大时,这时候多个信道复用一个Connection就会产生性能瓶颈,就需要开辟多个Connection,将这些信道均摊到这些Connection中。

posted @ 2021-02-03 22:09  Stacking  阅读(426)  评论(0编辑  收藏  举报