RabbitMQ原理介绍

RabbitMQ历史RabbitMQ消息系统是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。在同步消息通讯的世界里有很多公开标准（如COBAR的IIOP，或者是SOAP等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的MSMQ ，IBM的Websphere MQ等），因此，在2006年的6月，Cisco 、Redhat、iM..

weixin_33785108

61人浏览 · 2018-08-24 23:53:00

weixin_33785108 · 2018-08-24 23:53:00 发布

RabbitMQ历史

RabbitMQ消息系统是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。在同步消息通讯的世界里有很多公开标准（如COBAR的IIOP，或者是SOAP等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的MSMQ ，IBM的Websphere MQ等），因此，在2006年的6月，Cisco 、Redhat、iMatix 等联合制定了AMQP的公开标准。

RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。

RabbitMQ能为你做些什么？

言归正传，RabbitMQ，或者说AMQP解决了什么问题，或者说它的应用场景是什么？

消息系统允许软件应用相互连接和扩展，这些应用可以相互链接起来组成一个更大的应用，或者将用户设备和数据进行连接。消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶。或许你正在考虑进行数据投递，非阻塞操作或推送通知。或许你想要实现发布／订阅，异步处理，或者工作队列。所有这些都属于消息系统的模式。RabbitMQ是一个消息代理，一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息再传输过程中的安全。

对于一个大型的软件系统来说，它会有很多的组件或者说模块或者说子系统。那么这些模块的如何通信？这和传统的IPC有很大的区别。传统的IPC很多都是在单一系统上的，模块耦合性很大，不适合扩展（Scalability）；如果使用socket那么不同的模块的确可以部署到不同的机器上，但是还是有很多问题需要解决。比如：

1）信息的发送者和接收者如何维持这个连接，如果一方的连接中断，这期间的数据如何方式丢失？

2）如何降低发送者和接收者的耦合度？

3）如何让Priority高的接收者先接到数据？

4）如何做到load balance？有效均衡接收者的负载？

5）如何有效的将数据发送到相关的接收者？也就是说将接收者subscribe 不同的数据，如何做有效的filter。

6）如何做到可扩展，甚至将这个通信模块发到cluster上？

7）如何保证接收者接收到了完整，正确的数据？

AMDQ协议解决了以上的问题，而RabbitMQ实现了AMQP。

Rabbitmq工作模式

如上图：

RabbitMQ Server

是一种传输服务，它的角色就是维护一条从Producer（生产者）到Consumer（消费者）的路线，保证数据能够按照指定的方式进行传输。但是这个保证也不是100%的保证，但是对于普通的应用来说这已经足够了。当然对于商业系统来说，可以再做一层数据一致性的防护，就可以彻底保证系统的一致性了。

Client A & B

也叫Producer（生产者），就是数据的发送方。一个Message（消息）有两个部分：payload（有效载荷）和label（标签）。payload顾名思义就是传输的数据。label是exchange的名字或者说是一个tag，它描述了payload，而且RabbitMQ也是通过这个label来决定把这个Message发给哪个Consumer（消费者）。AMQP仅仅描述了label，而RabbitMQ决定了如何使用这个label的规则。

Client 1 & 2 & 3

也叫Consumer（消费者），就是数据的接收方。把queue（队列）比作是一个有名字的邮箱，当有Message到达某个邮箱后，RabbitMQ把它发送给它的某个订阅者即Consumer。当然可能会把同一个Message发送给很多的Consumer。在这个Message中，只有payload，label已经被删掉了。对于Consumer来说，它是不知道谁发送的这个信息的。就是协议本身不支持。但是当然了如果Producer发送的payload包含了Producer的信息就另当别论了。

对于一个数据从Producer到Consumer的正确传递，还有三个概念需要明确：exchanges, queues and bindings。

Exchanges – 是生产者发布消息的通道。

Queue – 是消费者接受消息的通道。

Bindings – 是将消息从交换路由绑定到特定队列中的。

还有几个概念是上述图中没有标明的，那就是Connection（连接），Channel（通道，频道）。

Connection – 就是一个TCP的连接，Producer和Consumer都是通过TCP连接到RabbitMQ Server的。以后我们可以看到，程序的起始处就是建立这个TCP连接。

Channels – 虚拟连接，它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。

那么，为什么使用Channel，而不是直接使用TCP连接？

对于OS来说，建立和关闭TCP连接是有代价的，频繁的建立关闭TCP连接对于系统的性能有很大的影响，而且TCP的连接数也有限制，这也限制了系统处理高并发的能力。但是，在TCP连接中建立Channel是没有上述代价的。对于Producer或者Consumer来说，可以并发的使用多个Channel进行Publish或者Receive。有实验表明，1s的数据可以Publish10K的数据包。当然对于不同的硬件环境，不同的数据包大小这个数据肯定不一样，但是我只想说明，对于普通的Consumer或者Producer来说，这已经足够了。如果不够用，你考虑的应该是如何细化split你的设计。