RabbitMQ基础知识

1.基本概念

1.1 队列(Queue)

队列是常用的数据结构之一，是一种特殊的线性表，特殊之处在于它只允许在表的前端(front)进行删除操作，而在表的后端(rear)进行插入操作。
进行插入操作的端称为队尾，进行删除操作的端称为对头。

在Java中,java.util包下已经有队列的相关实现，我们可以直接使用。

1.2 消息队列(Message Queue)

消息是计算机/应用间传送的数据单位，可以非常简单，例如只包含文本字符串，也可以很复杂，可能包含嵌入对象。
消息队列是在消息的传输过程中保存消息的容器。
消息传输时，先发送到队列，队列的主要目的是提供路由并保证消息的传递，如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功的传递它。
可以把消息队列理解成快递公司，你需要寄一个物件（消息）给你的朋友，快递公司收到物件会保证物件送到你的朋友手中，可能存在多次寄送才送达成功的情况，比如第一次送过去，你朋友不在家。
也许有人好奇，为什么我们不直接使用JDK自带的队列，而是要使用消息队列呢？
这是因为JDK自带的队列都存储在内存中，一但应用或者服务器挂了，消息就丢失了，使用消息队列可以避免消息丢失问题（注意不是100%不丢失），就像快递公司会保证你的物件寄到你的朋友手中，但肯定有丢件的几率。

1.3 RabbitMQ是什么

RabbitMQ是一个基于AMQP协议的高级消息中间件，它主要的技术特点是可用性，安全性，高可用集群，多协议支持，可视化的客户端，活跃的社区。支持死信队列，优先级队列，延迟队列，重试队列等多种功能。一般单机的QPS在万级左右，可以满足一般的应用场景。文档说明非常丰富，社区活跃，上手容易。强大的可视化管理工具。

2.AMQP模型

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

通过上面这张应用相结合的结构图既能够清晰的看清楚整体的send Message到Receive Message的一个大致的流程。当然上面有很多名词都相比还没有介绍到，不要着急接下来我们就开始对其进行详细的讲解。

Broker

消息代理，实际上就是消息服务器实体。

Binding

它的作用就是把交换机和队列按照路由规则绑定起来。

Routing Key

路由关键字，交换机根据这个关键字进行消息投递。

Virtaul Host

虚拟主机，一个消息代理里面可以开设多个虚拟主机进行逻辑隔离，用于不同用户的权限分离。

Connection

AMQP连接通常是长连接，Producer和Consumer都是通过TCP连接到RabbitMQ Server的。Connection是RabbitMQ的socket链接，它封装了socket协议相关部分逻辑ConnectionFactory为Connection的制造工厂。

Channel

AMQP通过Channle来处理多连接，可以把通道理解成共享一个TCP连接的多个轻量化连接。Channel是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。

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里面类型。
我来用表格来描述下类型以及类型之间的区别。

• 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这个规则就是模糊匹配，可以通过通配符满足一部分规则就可以传送。它的约定是：

routing key为一个句点号“. ”分隔的字符串（我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
binding key与routing key一样也是句点号“. ”分隔的字符串
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属性进行匹配。

参考：
https://www.cnblogs.com/dwlsxj/p/RabbitMQ.html