首页 > 程序开发 > 软件开发 > 其他 >

RabbitMQ之理论篇

2016-11-21

谈到RabbitMQ,首先要谈到MQ和AMQP MQ全称为MessageQueue,消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需用专用连接来链接它们。

谈到RabbitMQ,首先要谈到MQ和AMQP.MQ全称为MessageQueue,消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需用专用连接来链接它们。 消息服务擅长于解决多系统、异构系统间的数据交换(消息通知/通讯)问题,你也可以把它用于系统间服务的相互调用(RPC)。本文将要介绍的RabbitMQ就是当前最主流的消息中间件之一。

RabbitMQ简介

AMQP,即Advanced MessageQueuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。消息中间件主要用于组件之间的解耦,消息的发送者无需知道消息使用者的存在,反之亦然。

AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。

RabbitMQ是一个开源的AMQP实现,服务器端用Erlang语言编写,支持多种客户端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗。

基本原理

RabbitMQ的两大核心组件是Exchange和Queue,以下是它的运行原理图:

\

图中,绿色的X就是Exchange,红色的是Queue,这两者都在Server端,又称作Broker,这部分是RabbitMQ实现的,而蓝色的则是客户端,通常有Producer和Consumer两种类型。

Exchange,又称交换器,它接受消息和路由信息,然后将消息发送给消息队

列。对于每个虚拟主机内部,交换器有独一无二的名字。应用程序在其权限范围之内可以自由的创建、共享、使用和销毁交换器实例。

交换器可以是持久的、临时的或者自动删除的。持久交换器会一直存在于服务器,直到它被显式删除;临时交换器会工作到服务器被关闭时为止;而一旦没有应用程序使用自动删除交换器,它就会被服务器自动删除掉。

消息队列是一个具名缓冲区,它们代表一组消费者应用程序保存消息。应用程序在其权限范围之内可以自由的创建、共享、使用和消费消息队列。消息队列提供了有限制的先进先出保证。服务器会将从某一个生产者发

出的同等优先级的消息按照它们进入队列的顺序传递给某个消费者,万一某些消息不能被消费者处理,它们可能会被打乱顺序重新传递。

消息队列可以是持久的、临时的或者自动删除的。临时消息队列会工作到服务器被关闭时为止;而一旦没有应用程序使用自动删除消息队列,它就会被服务器自动删除掉。只要用户(客户端)拥有相应的权限,任何队列都可以被显式删除。

消息队列将消息保存在内存、硬盘,或者这两种介质的组合之中。消息队列限定在虚拟主机范围之中。消息队列保存消息,并将消息分发给一个或多个订阅客户端。

消息队列会跟踪消息的获取情况,消息要出队就必须被获取(acquire和consume是两个动作,先执行acquire,相当于对消息加锁)。这阻止了多个客户端同时获取和消费同一条消息,也可以被用来做单个队列多个消费者之间的负载均衡。

下面将重点介绍RabbitMQ中的一些基础概念,了解了这些概念,是使用好RabbitMQ的基础。

ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接,它封装了socket协议相关部分逻辑。ConnectionFactory为Connection的制造工厂。

Channel是我们与RabbitMQ打交道的最重要的一个接口,我们大部分的业务操作是在Channel这个接口中完成的,包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。

RabbitMQ中实现RPC的机制

\

客户端发送请求(消息)时,在消息的属性(MessageProperties,在AMQP协议中定义了14中properties,这些属性会随着消息一起发送)中设置两个值replyTo(一个Queue名称,用于告诉服务器处理完成后将通知我的消息发送到这个Queue中)和correlationId(此次请求的标识号,服务器处理完成后需要将此属性返还,客户端将根据这个id了解哪条请求被成功执行了或执行失败)

服务器端收到消息并处理

服务器端处理完消息后,将生成一条应答消息到replyTo指定的Queue,同时带上correlationId属性

客户端之前已订阅replyTo指定的Queue,从中收到服务器的应答消息后,根据其中的correlationId属性分析哪条请求被执行了,根据执行结果进行后续业务处理

RabbitMQ Server: 也叫broker server,它不是运送食物的卡车,而是一种传输服务。原话是RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是维护一条从Producer到Consumer的路线,保证数据能够按照指定的方式进行传输。但是这个保证也不是100%的保证,但是对于普通的应用来说这已经足够了。当然对于商业系统来说,可以再做一层数据一致性的guard,就可以彻底保证系统的一致性了。

Client A & B: 也叫Producer,数据的发送方。createmessagesand publish (send) them to a broker server (RabbitMQ).一个Message有两个部分:payload(有效载荷)和label(标签)。payload顾名思义就是传输的数据。label是exchange的名字或者说是一个tag,它描述了payload,而且RabbitMQ也是通过这个label来决定把这个Message发给哪个Consumer。AMQP仅仅描述了label,而RabbitMQ决定了如何使用这个label的规则。

Client 1,2,3:也叫Consumer,数据的接收方。Consumersattachto a broker server (RabbitMQ) and subscribe to a queue。把queue比作是一个有名字的邮箱。当有Message到达某个邮箱后,RabbitMQ把它发送给它的某个订阅者即Consumer。当然可能会把同一个Message发送给很多的Consumer。在这个Message中,只有payload,label已经被删掉了。对于Consumer来说,它是不知道谁发送的这个信息的。就是协议本身不支持。但是当然了如果Producer发送的payload包含了Producer的信息就另当别论了。

相关文章
最新文章
热点推荐