RabbitMQ原理介绍

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你的设计。

Rabbitmq技术亮点

1）可靠性

RabbitMQ提供了多种技术可让你在性能和可靠性之间进行权衡。这些技术包括持久性、投递确认、发布者证明和高可用性。

2）灵活的路由

消息在到达队列前是经过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。若是你有更复杂的路由需求，能够将这些交换机组合起来使用，甚至你能够写本身的交换机类型，而且当作RabbitMQ的插件来使用。

3）集群

在相同局域网中的多个RabbitMQ服务器能够被聚合在一块儿，做为一个独立的逻辑代理来使用。

4）联合

对于服务器来讲，它比集群须要更多的松散和非可靠连接。为此RabbitMQ提供了联合模型。

5）高可用的队列

在同一个集群中，队列能够被镜像到多个机器中，以确保当其中某些硬件出现事故后，你的消息仍然是安全的。

6）多协议

RabbitMQ 支持多种消息协议中的消息传递。

7）普遍的客户端

只要是你能想到的语言几乎都有与其相适配的RabbitMQ客户端。

8）可视化管理工具

RabbitMQ附带了一个易于使用的可视化管理工具，它能够帮助你监控消息代理的每个环节。

9）追踪

若是你的消息系统有异常行为，RabbitMQ还提供了追踪的支持，让你可以发现问题所在。

10）插件系统

RabbitMQ附带了各类各样的插件来对本身进行扩展。甚至你也能够写本身的插件来使用。

11）还有什么呢…

商业支持

能够提供商业支持，包括培训和咨询。

大型社区

围绕着RabbitMQ有一个大型的社区，在那儿产生了各类各样的客户端、插件、指南等等。

关于RabbitMQ

RabbitMQ是使用Erlang开发的一个消息队列，能够构建成集群，也能够单独使用。

根据测试，RabbitMQ在不使用ACK机制的，Msg大小为1K的状况下，QPS可达6W＋。再双方ACK机制，Msg大小为1K的状况下，QPS瞬间降到了1W＋。从某种意义上RabbitMQ还真是慢，可是咱们须要思考下。

1. 咱们真的每一个消息都能到1K吗？
2. 咱们真的须要双方都对消息ACK的系统吗？

好了，若是两个回答都是YES，那么RabbitMQ就是慢的。若是是No，那么RabbitMQ仍是一个很是快的队列。

RabbitMQ慢有几个缘由？

1. RabbitMQ作为一个Broker，不仅仅作到了简单的数据转发功能，还保证了单个队列上的数据有序，即使是有多个消费者和多个生产者。
2. RabbitMQ的策略是实时转发，而不像Kafka那样等待刷盘以后才让消费者来消费。
3. 若是消费者和生产者不对等，会产生大量的磁盘IO操做，进行消息换出。

RabbitMQ为何很差用？

1. AMQP协议自己比较复杂，参数比较多。
2. Erlang写的，不少人不熟悉，而且Mnesia出现问题好多人解决不了。

RabbitMQ该怎么用？

1. RabbitMQ的消息应当尽量的小，而且只用来处理实时且要高可靠性的消息。
2. 消费者和生产者的能力尽可能对等，不然消息堆积会严重影响RabbitMQ的性能。
3. 集群部署，使用热备，保证消息的可靠性。

RabbitMQ 中文文档

http://rabbitmq.mr-ping.com/