最全面透彻的RabbitMQ指南

概念

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

RabbitMQ是一套开源（MPL）的消息队列服务软件，是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成。

AMQP

AMQP 其实和Http一样 都是一种协议， 只不过 Http是针对网络传输的， 而AMQP是基于消息队列的

AMQP 协议中的基本概念

**Broker: **

接收和分发消息的应用，我们在介绍消息中间件的时候所说的消息系统就是Message Broker。

**Virtual host: **

出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。

「Connection:」

publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。

**Channel: **

如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。

「Exchange:」

message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。

**Queue: **

消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。

「Binding:」

exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。

Exchange的类型

「direct :」

这种类型的交换机的路由规则是根据一个routingKey的标识，交换机通过一个routingKey与队列绑定 ，在生产者生产消息的时候 指定一个routingKey 当绑定的队列的routingKey 与生产者发送的一样 那么交换机会吧这个消息发送给对应的队列。

「fanout:」

这种类型的交换机路由规则很简单，只要与他绑定了的队列， 他就会吧消息发送给对应队列（与routingKey没关系）

「topic:」

(因为*在这个笔记软件里面是关键字，所以下面就用星替换掉了)这种类型的交换机路由规则也是和routingKey有关 只不过 topic他可以根据:星,#（ 星号代表过滤一单词，#代表过滤后面所有单词， 用.隔开）来识别routingKey 我打个比方 假设 我绑定的routingKey 有队列A和B A的routingKey是：星.user B的routingKey是: #.user

那么我生产一条消息routingKey 为：error.user 那么此时 2个队列都能接受到， 如果改为 topic.error.user 那么这时候 只有B能接受到了

「headers:」

这个类型的交换机很少用到，他的路由规则 与routingKey无关 而是通过判断header参数来识别的， 基本上没有应用场景，因为上面的三种类型已经能应付了。

执行过程

1.客户端连接到消息队列服务器，打开一个Channel。

2.客户端声明一个Exchange，并设置相关属性。

3.客户端声明一个Queue，并设置相关属性。

4.客户端使用Routing key，在Exchange和Queue之间建立好绑定关系。

5.客户端投递消息到Exchange。

Exchange接收到消息后，就根据消息的key和已经设置的Binding，进行消息路由，将消息投递到一个或多个队列里。有三种类型的Exchanges：direct，fanout，topic，每个实现了不同的路由算法：

消息的ack机制

默认情况下，如果Message 已经被某个Consumer正确的接收到了，那么该Message就会被从queue中移除。当然也可以让同一个Message发送到很多的Consumer。

如果一个queue没被任何的Consumer Subscribe（订阅），那么，如果这个queue有数据到达，那么这个数据会被cache，不会被丢弃。当有Consumer时，这个数据会被立即发送到这个Consumer，这个数据被Consumer正确收到时，这个数据就被从queue中删除。

消息持久化

RabbitMQ支持消息的持久化，也就是数据写在磁盘上，为了数据安全考虑，大多数用户都会选择持久化。消息队列持久化包括3个部分：

1.Exchange持久化，在声明时指定durable => 1

2.Queue持久化，在声明时指定durable => 1

3.消息持久化，在投递时指定delivery_mode => 2（1是非持久化）

若Exchange和Queue都是持久化的，那么它们之间的Binding也是持久化的；而Exchange和Queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。

特性

可伸缩性：集群服务

消息持久化：从内存持久化消息到硬盘，再从硬盘加载到内存

支持的操作系统

1、Linux

2、WindowsNT到10

3、VxWorks

4、macOS

5、FreeBSD

6、Windows Server2003到2016

7、Solaris

8、TRU64

支持的编程语言

1、Swift

2、Java

3、Elixir

4、Python

5、JavaScript

6、Objective-C

7、Go

8、Ruby

9、C#

7、Ruby

8、PHP

使用场景

1. 解耦（为面向服务的架构（SOA）提供基本的最终一致性实现）

2. 异步提升效率

3. 流量削峰，流量削峰也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛

优缺点

在特殊场景下有其对应的好处，解耦、异步、削峰。

「缺点」

1、系统的可用性降低

系统引入的外部依赖越多，系统越容易挂掉。

2、系统的复杂性提高

引入了MQ之后，需要考虑的问题也变得多了，如何保证消息没有重复消费？如何保证消息不丢失？怎么保证消息传递的顺序？

3、一致性问题

A系统发送完消息直接返回成功，但是BCD系统之中若有系统写库失败，则会产生数据不一致的问题。这就涉及到分布式事务的问题。