RabbitMQ之理论篇

谈到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的信息就另当别论了。