RabbitMQ基础知识

1、背景

RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通信的世界里有不少公开标准（如 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的官网是 http://www.rabbitmq.com

2、基本概念

讲解基础概念的前面，咱们先来总体构造一个结构图，这样会方便们更好地去理解RabbitMQ的基本原理。

经过上面这张应用相结合的结构图既可以清晰的看清楚总体的send Message到Receive Message的一个大体的流程。固然上面有不少名词都相比尚未介绍到，不要着急接下来咱们就开始对其进行详细的讲解。

• Queue

  Queue（队列）RabbitMQ的做用是存储消息，队列的特性是先进先出。上图能够清晰地看到Client A和Client B是生产者，生产者生产消息最终被送到RabbitMQ的内部对象Queue中去，而消费者则是从Queue队列中取出数据。能够简化成表示为：
  

生产者Send Message “A”被传送到Queue中，消费者发现消息队列Queue中有订阅的消息，就会将这条消息A读取出来进行一些列的业务操做。这里只是一个消费正对应一个队列Queue，也能够多个消费者订阅同一个队列Queue，固然这里就会将Queue里面的消息平分给其余的消费者，可是会存在一个一个问题就是若是每一个消息的处理时间不一样，就会致使某些消费者一直在忙碌中，而有的消费者处理完了消息后一直处于空闲状态，由于前面已经说起到了Queue会平分这些消息给相应的消费者。这里咱们就可使用prefetchCount来限制每次发送给消费者消息的个数。详情见下图所示：

这里的prefetchCount=1是指每次从Queue中发送一条消息来。等消费者处理完这条消息后Queue会再发送一条消息给消费者。

• Exchange

  咱们在开篇的时候就留了一个坑，就是那个应用结构图里面，消费者Client A和消费者Client B是如何知道我发送的消息是给Queue1仍是给Queue2，有没有过这个问题，那么咱们就来解开这个面纱，看看究竟是个什么构造。首先明确一点就是生产者产生的消息并非直接发送给消息队列Queue的，而是要通过Exchange（交换器），由Exchange再将消息路由到一个或多个Queue，固然这里还会对不符合路由规则的消息进行丢弃掉，这里指的是后续要谈到的Exchange Type。那么Exchange是怎样将消息准确的推送到对应的Queue的呢？那么这里的功劳最大的当属Binding，RabbitMQ是经过Binding将Exchange和Queue连接在一块儿，这样Exchange就知道如何将消息准确的推送到Queue中去。简单示意图以下所示：
  

在绑定（Binding）Exchange和Queue的同时，通常会指定一个Binding Key，生产者将消息发送给Exchange的时候，通常会产生一个Routing Key，当Routing Key和Binding Key对应上的时候，消息就会发送到对应的Queue中去。那么Exchange有四种类型，不一样的类型有着不一样的策略。也就是代表不一样的类型将决定绑定的Queue不一样，换言之就是说生产者发送了一个消息，Routing Key的规则是A，那么生产者会将Routing Key=A的消息推送到Exchange中，这时候Exchange中会有本身的规则，对应的规则去筛选生产者发来的消息，若是可以对应上Exchange的内部规则就将消息推送到对应的Queue中去。那么接下来就来详细讲解下Exchange里面类型。

• Exchange Type

  我来用表格来描述下类型以及类型之间的区别。

  • fanout
    fanout类型的Exchange路由规则很是简单，它会把全部发送到该Exchange的消息路由到全部与它绑定的Queue中。

上图所示，生产者（P）生产消息1将消息1推送到Exchange，因为Exchange Type=fanout这时候会遵循fanout的规则将消息推送到全部与它绑定Queue，也就是图上的两个Queue最后两个消费者消费。

• direct
  direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key彻底匹配的Queue中

当生产者（P）发送消息时Rotuing key=booking时，这时候将消息传送给Exchange，Exchange获取到生产者发送过来消息后，会根据自身的规则进行与匹配相应的Queue，这时发现Queue1和Queue2都符合，就会将消息传送给这两个队列，若是咱们以Rotuing key=create和Rotuing key=confirm发送消息时，这时消息只会被推送到Queue2队列中，其余Routing Key的消息将会被丢弃。

• topic
  前面提到的direct规则是严格意义上的匹配，换言之Routing Key必须与Binding Key相匹配的时候才将消息传送给Queue，那么topic这个规则就是模糊匹配，能够经过通配符知足一部分规则就能够传送。它的约定是：

1.routing key为一个句点号“. ”分隔的字符串（咱们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
2.binding key与routing key同样也是句点号“. ”分隔的字符串
3.binding key中能够存在两种特殊字符“”与“#”，用于作模糊匹配，其中“”用于匹配一个单词，“#”用于匹配多个单词（能够是零个）

当生产者发送消息Routing Key=F.C.E的时候，这时候只知足Queue1，因此会被路由到Queue中，若是Routing Key=A.C.E这时候会被同是路由到Queue1和Queue2中，若是Routing Key=A.F.B时，这里只会发送一条消息到Queue2中。

• headers
  headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。
  在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否彻底匹配Queue与Exchange绑定时指定的键值对；若是彻底匹配则消息会路由到该Queue，不然不会路由到该Queue。
  该类型的Exchange没有用到过（不过也应该颇有用武之地），因此不作介绍。

  ---

  这里在对其进行简要的表格整理：

Exchange规则

类型名称	类型描述
fanout	把全部发送到该Exchange的消息路由到全部与它绑定的Queue中
direct	Routing Key==Binding Key
topic	我这里本身总结的简称模糊匹配
headers	Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。

补充说明：

　　ConnectionFactory、Connection、Channel
　　ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket连接，它封装了socket协议相关部分逻辑。ConnectionFactory为Connection的制造工厂。
　　Channel是咱们与RabbitMQ打交道的最重要的一个接口，咱们大部分的业务操做是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。

　　Connection就是创建一个TCP链接，生产者和消费者的都是经过TCP的链接到RabbitMQ Server中的，这个后续会再程序中体现出来。

　　Channel虚拟链接，创建在上面TCP链接的基础上，数据流动都是经过Channel来进行的。为何不是直接创建在TCP的基础上进行数据流动呢？若是创建在TCP的基础上进行数据流动，创建和关闭TCP链接有代价。频繁的创建关闭TCP链接对于系统的性能有很大的影响，并且TCP的链接数也有限制，这也限制了系统处理高并发的能力。可是，在TCP链接中创建Channel是没有上述代价的。

3、参考

1.转载来自：https://www.cnblogs.com/dwlsxj/p/RabbitMQ.html